International organisation for standardisation organisation internationale de normalisation
|
|  Yüklə 1.39 Mb.
|
Annex B(Normative) CRC Decoder Model B.0 CRC decoder modelThe 32 bit CRC Decoder Model is specified in Figure B-1 below. 
Figure B-1 -- 32 bit CRC decoder model The 32 bit CRC Decoder operates at bit level and consists of 14 adders '+' and 32 delay elements z(i). The input of the CRC decoder is added to the output of z(31), and the result is provided to the input z(0) and to one of the inputs of each remaining adder. The other input of each remaining adder is the output of z(i), while the output of each remaining adder is connected to the input of z(i+1), with i = 0, 1, 3, 4, 6, 7 , 9, 10, 11, 15, 21, 22, and 25. Refer to Figure B-1 above. This is the CRC calculated with the polynomial: x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x +1. (B-1) Bytes are received at the input of the CRC decoder. Each byte is shifted into the CRC decoder one bit at a time, with the left most bit (msb) first. For example, if the input is byte 0x01 the seven '0's enter the CRC decoder first, followed by the one '1'. Before the CRC processing of the data of a section the output of each delay element z(i) is set to its initial value '1'. After this initialization, each byte of the section is provided to the input of the CRC decoder, including the four CRC_32 bytes. After shifting the last bit of the last CRC_32 byte into the decoder, i. e. into z(0) after the addition with the output of z(31), the output of all delay elements z(i) is read. In the case where there are no errors, each of the outputs of z(i) shall be zero. At the CRC encoder the CRC_32 field is encoded with a value such that this is ensured. Annex C(Informative.) Program Specific Information C.0 Explanation of Program Specific Information in Transport StreamsSection 2.4.4 contains the normative syntax, semantics and text concerning Program Specific Information. In all cases, compliance with the constraints of section 2.4.4 is required. This annex provides explanatory information on how to use the PSI functions, and considers examples of how it may be used in practice. C.1 IntroductionITU T Rec. H.222.0†|†ISO/IEC 13818-1 provides a method for describing the contents of Transport Stream packets for the purpose of the demultiplexing and presentation of programs. The coding specification accommodates this function through the Program Specific Information (PSI). This annex discusses the use of PSI. The PSI may be thought of as belonging to four tables:
The contents of the PAT, PMT and CAT are specified in this standard. The NIT is a private table, but the PID value of the Transport Stream packets which carry it is specified in the PAT. It must however follow the section structure defined in this standard. C.2 Functional MechanismThe tables listed above are conceptual in that they need never be regenerated in a specified form within a decoder. While these structures may be thought of as simple tables, they may be partitioned before they are sent in Transport Stream packets. The syntax supports this operation by allowing the tables to be partitioned into sections and by providing a normative mapping method into Transport Stream packet payloads. A method is also provided to carry private data in a similar format. This is advantageous as the same basic processing in the decoder can then be used for both the PSI data and the private data helping to keep cost down. For advice on the optimum placing of PSI in the Transport Stream, see Annex D. Each section is uniquely identified by the combination of the following elements: i) table_id The 8 bit table_id identifies to which table the section belongs. Sections with table_id 0x00 belong to the Program Association Table. Sections with table_id 0x01 belong to the Conditional Access Table. Sections with table_id 0x02 belong to the TS Program Map Table.
C.3 The Mapping of Sections into Transport Stream PacketsSections are mapped directly into Transport Stream packets, that is to say without a prior mapping into PES packets. Sections do not have to start at the beginning of Transport Stream packets, (although they may), because the start of the first section in the payload of a Transport Stream packet is pointed to by the pointer_field. The presence of the pointer_field is signaled by the payload_unit_start_indicator being set to a value of '1' in PSI packets. (In non-PSI packets, the indicator signals that a PES packet starts in the Transport Stream packet). The pointer_field points to the start of the first section in the Transport Stream packet. There is never more than one pointer_field in a Transport Stream packet, as the start of any other section can be identified by counting the length of the first and any subsequent sections, since no gaps between sections within a Transport Stream packet are allowed by the syntax. It is important to note that within Transport Stream packets of any single PID value, one section must be finished before the next one is allowed to be started, or else it is not possible to identify to which section header the data belongs. If a section finishes before the end of a Transport Stream packet, but it is not convenient to open another section, a stuffing mechanism is provided to fill up the space. Stuffing is performed by filling each remaining byte of the packet with the value 0xFF. Consequently the table_id value 0xFF is forbidden, or else this would be confused with stuffing. Once a 0xFF byte has occurred at the end of a section, then the rest of the Transport Stream packet must be stuffed with 0xFF bytes, allowing a decoder to discard the rest of the Transport Stream packet. Stuffing can also be performed using the normal adaptation_field mechanism. C.4 Repetition Rates and Random AccessIn systems where random access is a consideration, it is recommended to re-transmit PSI sections several times, even when changes do not occur in the configuration, as in the general case, a decoder needs the PSI data to identify the contents of the Transport Stream, to be able to start decoding. ITU T Rec. H.222.0†|†ISO/IEC 13818-1 does not place any requirements on the repetition or occurrence rate of PSI sections. Clearly though, repeating sections frequently helps random access applications, whilst causing an increase in the amount of bitrate used by PSI data. If program mappings are static or quasi-static, they may be stored in the decoder to allow faster access to the data than having to wait for it to be re-transmitted. The trade-off between the amount of storage required and the desired impact on channel acquisition time may be made by the decoder manufacturer. C.5 What is a Program?The concept of a program has a precise definition within this standard (refer to 2.1.42 program [system]). For a Transport Stream the time base is defined by the PCR. This effectively creates a virtual channel within the Transport Stream. Note that this is not the same definition as is commonly used in broadcasting, where a "program" is a collection of elementary streams not only with a common timebase, but also with a common start and end time. A series of "broadcaster programs" (referred to in this annex as events) can be transmitted sequentially in a Transport Stream using the same program_number to create a "broadcasting conventional" TV channel (sometimes called a service). Event descriptions could be transmitted in private_sections(). A program is denoted by a program_number which has significance only within a Transport Stream. The program_number is a 16-bit unsigned integer and thus permits 65535 unique programs to exist within a Transport Stream (program_number 0 is reserved for identification of the NIT). Where several Transport Streams are available to the decoder (e.g. in a cable network), in order to successfully demultiplex a program, the decoder must be notified of both the transport_stream_id (to find the right multiplex) and the program_number of the service (to find the right program within the multiplex). The Transport Stream mapping may be accomplished via the optional Network Information Table. Note that the Network Information Table may be stored in decoder non-volatile memory to reduce channel acquisition time. In this case, it needs to be transmitted only often enough to support timely decoder initialization setup operations. The contents of the NIT are private, but shall take at least the minimum section structure. C.6 Allocation of program_numberIt may not be convenient in all cases to group together all the program element which share a common clock reference as one program. It is conceivable to have a multi-service Transport Stream with only one set of PCRs, common to all. In general, though, a broadcaster may prefer to logically split up the Transport Stream into several programs, where the PCR_PID (location of the clock reference) is always the same. This method of splitting the program elements into pseudo-independent programs can have several uses; two examples follow: i) multilingual transmissions into separate markets One video stream may be accompanied by several audio streams in different languages. It is advisable to include an example of the ISO_639_language_descriptor associated with each audio stream to enable the selection of the correct program and audio. It is reasonable to have several program definitions with different program_numbers, where all the programs reference the same video stream and PCR_PID, but have different audio PIDs. It is however also reasonable and possible to list the video stream and all the audio streams as one program, where this does not exceed the section size limit of 1024 bytes. ii) Very large program definitions There is a maximum limit on the length of a section of 1024 bytes (including section header and CRC_32). This means that no single program definition may exceed this length. For the great majority of cases, even with each program elements having several descriptors, this size is adequate. However, one may envisage cases in very high bitrate systems, which could exceed this limit. It is then in general possible to identify methods of splitting the references of the streams, so that they do not all have to be listed together. Some program elements could be referenced under more than one program, and some under only one or the other, but not both. C.7 Usage of PSI in a Typical SystemA communications system, especially in broadcast applications, may consist of many individual Transport Streams. Each one of the four PSI data structures may appear in each and every Transport Stream in a system. There must always be a complete version of the program association table listing all programs within the Transport Stream and a complete TS program map table, containing complete program definitions for all programs within the Transport Stream. If any streams are scrambled, then there must also be a conditional access table present listing the relevant EMM streams (Entitlement Management Messages). The presence of a NIT is fully optional. The PSI tables are mapped into Transport Stream packets via the section structure described above. Each section has a table_id field in its header, allowing sections from PSI tables and private data in private_sections to be mixed in Transport Stream packets of the same PID value or even in the same Transport Stream packet. Note however that within packets of the same PID a complete section must be transmitted before the next section can be started. This is only possible for packets labeled as containing TS Program Map Table section or NIT packets however, since private sections may not be mapped into PAT or CAT packets. It is required that all PAT sections be mapped into Transport Stream packets with PID=0x0000 and all CA sections be mapped into packets with PID=0x0001. PMT sections may be mapped into packets of user-selected PID value, listed as the PMT_PID for each program in the Program Association Table. Likewise, the PID for the NIT-bearing Transport Stream packets is user-selected, but must be pointed to by the entry "program_number == 0x00" in the PAT, if the NIT exists. The contents of any CA parameter streams are entirely private, but EMMs and ECMs must also be sent in Transport Stream packets to be compliant with the standard. Private data tables may be sent using the private_section() syntax. Such tables could be used for example in a broadcasting environment to describe a service, an upcoming event, broadcast schedules and related information. C.8 The Relationships Of PSI StructuresFigure C-1 shows an example of the relationship between the four PSI structures and the Transport Stream. Other examples are possible, but the figure shows the primary connections. In the following sections, each PSI table is described. 
Figure C-1 -- Program and network mapping relationships C.8.1 Program Association TableEvery Transport Stream must contain a complete valid Program Association Table. The Program Association Table gives the correspondence between a program_number and the PID of the Transport Stream packets that carry the definition of that program (the PMT_PID). The PAT may be partitioned into up to 255 sections before it is mapped into Transport Stream packets. Each section carries a part of the overall PAT. This partitioning may be desirable to minimize data loss in error conditions. That is, packet loss or bit errors may be localized to smaller sections of the PAT, thus allowing other sections to still be received and correctly decoded. If all PAT information is put into one section, an error causing a changed bit in the table_id, for example, would cause the loss of the entire PAT. However, this is still permitted as long as the section does not extend beyond the 1 024 byte maximum length limit. Program 0 (zero) is reserved and is used to specify the Network PID. This is a pointer to the Transport Stream packets which carry the Network Information Table. The Program Association Table is always transmitted without encryption. C.8.2 Program Map TableThe Program Map Table provides the mapping between a program number and the program elements that comprise it. This table is present in Transport Stream packets having one or more privately-selected PID values. These Transport Stream packets may contain other private structures as defined by the table_id field. It is possible to have TS PMT sections referring to different programs carried in Transport Stream packets having a common PID value. ITU T Rec. H.222.0†|†ISO/IEC 13818-1 requires a minimum of program identification: program number, PCR PID, stream types and program elements PIDs. Additional information for either programs or elementary streams may be conveyed by use of the descriptor() construct. Refer to section C.8.6. Private data may also be sent in Transport Stream packets denoted as carrying TS program map table sections. This is accomplished by the use of the private_section(). In a private_section() the application decides whether version_number and current_next_indicator represent the values of these fields for a single section or whether they are applicable to many sections as parts of a larger private table. Note 1 -- Transport stream packets containing the Program Map Table are transmitted unencrypted. Note 2 -- It is possible to transmit information on events in private descriptors carried within the TS_program_map_section()s. C.8.3 Conditional Access TableThe Conditional Access (CA) Table gives the association between one or more CA systems, their EMM streams and any special parameters associated with them. Note: The (private) contents of the Transport Stream packets containing EMM and CA parameters if present will, in general, be encrypted (scrambled). C.8.4 Network Information TableThe contents of the NIT are private and not specified by this standard. In general, it will contain mappings of user-selected services with transport_stream_ids, channel frequencies, satellite transponder numbers, modulation characteristics, etc. C.8.5 Private_section()Private_sections() can occur in two basic forms, the short version (where only the fields up to and including section_length are included) or the long version (where all the fields up to and including last_section_number are present, and after the private data bytes the CRC_32 field is present). Private_section()s can occur in PIDs which are labeled as PMT_PIDs or in Transport Stream packets with other PID values which contain exclusively private_sections(), including the PID allocated to the NIT. If the Transport Stream packets of the PID carrying the private_section()s are identified as a PID carrying private_sections (stream_type assignment value 0x05) then only private_sections may occur in Transport Stream packets of that PID value; the sections may be either of the short or long type. C.8.6 DescriptorsThere are several normative descriptors defined in this standard. Many more private descriptors may also be defined. All descriptors have a common format: {tag, length, data}. Any privately defined descriptors must adhere to this format. The data portion of these private descriptors are privately defined. One descriptor (the CA_descriptor()), is used to indicate the location (PID value of transport packets) of ECM data associated with program elements when it is found in a TS PMT section. When found in a CA section it refers to EMMs. In order to extend the number of private_descriptors available, the following mechanism could be used: A private descriptor_tag could be privately defined to be constructed as a composite descriptor. This entails privately defining a further sub_descriptor as the first field of the private data bytes of the private descriptor. The described structure is as follows:
C.9 Bandwidth Utilization and Signal Acquisition TimeAny implementation of an ITU T Rec. H.222.0†|†ISO/IEC 13818-1 bitstream must make reasonable bandwidth demands for PSI information and, in applications where random access is a consideration, should promote fast signal acquisition. This section analyses this issue and gives some broadcast application examples. The packet-based nature of the Transport Stream allows for the interspersing of PSI information with fine granularity in the multiplexed data. This provides significant flexibility in the construction and transmission of PSI. Signal acquisition time in a real decoder is dependent on many factors, including: FDM tuning slew time, demultiplexing time, sequence headers, I-frame occurrence rate and scrambling key retrieval and processing. This section examines both the bitrate and signal acquisition time impacts of the PSI syntax sections 2.4.4.4 and 2.4.4.9. It is assumed that the Conditional Access Table does not need to be received dynamically at every program change. This assumption is also made of the private EMM streams. This is because these streams do not contain the quickly-varying ECM components used for program element scrambling (encryption). Also, in the discussion below, the time to acquire and process ECMs has been neglected. The tables given below provide bandwidth usage values for a range of Transport Stream conditions. One axis of the table is the number of programs contained in a single Transport Stream. The other axis is the frequency with which the PSI information is transmitted in the Transport Stream. This frequency will be a key determinant of the component of signal acquisition time due to PSI structures. Both bandwidth usage tables assume that only the minimum program mapping information is provided. This means that the PID values and stream types are provided with no additional descriptors. All programs in the example are composed of two elementary streams. Program associations are 2 bytes long, while the minimal program map is 26 bytes long. There is additional overhead associated with version numbers, section lengths, etc. This will be on the order of 1-3% of the total PSI bitrate usage in sections of moderate to maximum length (a few hundred bytes to 1024 bytes) and will thus be ignored here. The above assumptions allow forty-six (46) program associations to map into one Program Association Table Transport Stream packet (if no adaptation field is present). Similarly, seven (7) TS_program_map_sections fit into a single Transport Stream packet. It may be noted that to facilitate easy "drop/add" it is possible to transmit only one (1) TS_program_map_section per PMT_PID. This may cause an undesirable increase in PSI bitrate usage, however. Table C-3 -- Program association table bandwidth usage (bps)
Note -- since 46 program_association_sections fit into one transport packet, the numbers in the table do not change until the last column.
Using a frequency of 25Hz for the two PSI Tables, yields a worst case contribution to the signal acquisition time of approximately 80 ms. This would only occur when the required PAT data was "just missed" and then, once the PAT was acquired and decoded, the required PMT data was also "just missed". This doubling of the worst case acquisition time is one disadvantage of the extra level of indirection introduced by the PAT structure. This effect could be reduced by coordinated transmission of related PAT and PMT packets. Presumably, the advantage that this approach offers for "drop/add" re-multiplexing operations is compensatory. With the 25Hz PSI frequency, the following examples may be constructed (all examples leave ample allowance for various datalink, FEC, CA and routing overheads): 6 MHz CATV channel: five 5.2-Mbps programs: 26.5 Mbps (includes transport overhead) total PSI bandwidth: 75.2 kbps CA bandwidth: 500 kbps total ITU T Rec. H.222.0†|†ISO/IEC 13818-1 transport bandwidth: 27.1 Mbps PSI Overhead: 0.28 % OC-3 fiber channel (155 Mbps): 32 3.9-Mbps programs: 127.5 Mbps (includes transport overhead) total PSI bandwidth: 225.6 kbps CA bandwidth: 500 kbps total ITU T Rec. H.222.0†|†ISO/IEC 13818-1 transport bandwidth: 128.2 Mbps PSI Overhead: 0.18% C-band satellite transponder: 128 256-kbps audio programs: 33.5 Mbps (includes transport overhead) total PSI bandwidth: 826.4 kbps CA bandwidth: 500 kbps total ITU T Rec. H.222.0†|†ISO/IEC 13818-1 transport bandwidth: 34.7 Mbps PSI Overhead: 2.4 % (actually would be lower if only one PID used per program) As expected, the percent overhead increases for lower-rate services since many more services are possible per Transport Stream. However, the overhead is not excessive in all cases. Higher transmission rates (than 25Hz) for the PSI data may be used to decrease the impact on channel acquisition time with only modest bitrate demand increases. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||