International organisation for standardisation organisation internationale de normalisation
Download 2.79 Mb.
|
- Navigate this page:
- G.0.2 Skipped picture status and decoding process
- G.0.3 Selection of PID Values
- Annex H
- Annex I
Annex G(Informative.) General Information G.0 General InformationG.0.1 Sync Byte EmulationIn the choice of PID values it is recommended that the periodic emulation of sync bytes should be avoided. Such emulation may potentially occur within the PID field or as a combination of the PID field and adjacent flag settings. It is recommended that emulation of the sync byte is permitted to occur in the same position of the packet header for a maximum of 4 consecutive transport packets. G.0.2 Skipped picture status and decoding processAssume that the sequence being displayed contains only I and P frames. Denote the next picture to be decoded by picture_next, and the picture currently being displayed by picture_current. Because of the fact that the video encoder may skip pictures, it is possible that not all of the bits of picture_next are present in the STD buffers EBn or Bn when the time arrives to remove those bits for instantaneous decoding and display. When this case arises, no bits are removed from the buffer and picture_current is displayed again. When the next picture display time arrives, if the remainder of the bits corresponding to picture_next are now in buffer EBn or Bn , all the bits of picture_next are removed and picture_next is displayed. If all the bits of picture_next are not in the buffer EBn or Bn, the above process of redisplaying picture_current is repeated. This process is repeated until picture_next can be displayed. Note that if a PTS preceded picture_next in the bitstream, it will be incorrect by some multiple of the picture display interval, which itself may depend on some parameters, and must be ignored. Whenever the skipped picture situation described above occurs, the encoder is required to insert a PTS before the picture to be decoded after picture_next. This allows the decoder to immediately verify that it has correctly displayed the received picture sequence. G.0.3 Selection of PID ValuesApplications are encouraged to use low numbered PID values (avoiding reserved values as specified in table 2-4) and group values together as much as possible. G.0.4 PES start_code emulationThree consecutive bytes having the value of a packet_start_code_prefix (0x000001), which when concatenated with a fourth byte, may emulate the four bytes of a PES_packet_header at a unintended place in the stream. Such, so called, start code emulation is not possible in video elementary streams. It is possible in audio and data elementary streams. It is also possible at the boundary of a PES_packet_header and a PES_packet payload, even if the PES_packet payload is video. Annex H(Informative.) Private Data H.0 Private DataPrivate data is any user data which is not coded according to a standard specified by ITU‑T†|†ISO/IEC and referred to in this Specification. The contents of this data is not and shall not be specified within ITU‑T Rec. H.222.0†|†ISO/IEC 13818-1 in the future. The STD defined in this specification does not cover private data other than the demultiplex process. A private party may define each STD for private streams. Private data may be carried in the following locations within the ITU‑T Rec. H.222.0†|†ISO/IEC 13818‑1 syntax. 1. Transport Stream packet table 2-2 on page 21. The data bytes of the transport_packet() syntax may contain private data. Private data carried in this format is referred to as user private within the stream_type table 2-29 on page 51. It is permitted for Transport Stream packets containing private data to also include adaptation_field()s. 2. Transport Stream Adaptation Field table 2-6 on page 23. The presence of any optional private_data_bytes in the adaptation_field() is signalled by the transport_private_data_flag. The number of the private_data_bytes is inherently restricted by the semantic of the adaptation_field_length field, where the value of the adaptation_field_length shall not exceed 183 bytes. 3. PES packet table 2-17 on page 33 There are two possibilities for carrying private data within PES packets. The first possibility is within the PES_packet_header, within the optional 16 bytes of PES_private_data. The presence of this field is signalled by the PES_private_data_flag. The presence of the PES_private_data_flag is signalled by the PES_extension_flag. If present, these bytes, when considered with the adjacent fields, shall not emulate the packet_start_code_prefix. The second possibility is within the PES_packet_data_byte field. This may be referred to as private data within PES packets under the stream_type table 2-29 on page 51. This category of private data can be split in two: private_stream_1 refers to private data within PES packets which follow the PES_packet() syntax such that all fields up to and including, but not limited to, PES_header_data_length are present; private_stream_2 refers to private data within PES packets where only the first three fields shall be present followed by the PES_packet_data_bytes containing private data. Note that PES packets exist within both Program Streams and Transport Streams therefore private_stream_1 and private_stream_2 exist within both Program Streams and Transport Streams. 4. Descriptors Descriptors exist within Program Streams and Transport Streams. A range of private descriptors may be defined by the user. These descriptors shall commence with descriptor_tag and descriptor_length fields. For private descriptors, the value of descriptor_tag may take the values 64 - 255 as identified in table 2-39 on page 68. These descriptors may be placed within a program_stream_map() table 2-29 on page 51, a CA_section() table 2-27 on page 49, a TS_program_map_section(), table2-28 on page 50 and in any private section(), table 2-30 on page 52. Specifically private_data_bytes also appear in the CA_descriptor(). 5. Private Section The private_section table 2-30 on page 52 provides a further means to carry private data also in two forms. This type of elementary stream may be identified under stream_type table 2-29 on page 51 as private_data in PSI sections. One type of private_section() includes only the first five defined fields, and is followed by private data. For this structure the section_syntax_indicator shall be set to a value of '0'. For the other type the section syntax indicator shall be set to a value of '1' and the full syntax up to and including last_section_number shall be present, followed by private_data_bytes and ending with the CRC_32. Annex I(Informative.) List of companies having provided patent statements for ITU‑T Rec. H.222.0†|†ISO/IEC 13818 The user's attention is called to the possibility that - for some of the processes specified in this Recommendation†|†International Standard conformance with this Recommendation†|†International Standard may require use of an invention covered by patent rights. By publication of this part of Recommendation†|†International Standard, no position is taken with respect to the validity of this claim or of any patent rights in connection therewith. However, each company listed in this annex has undertaken to file with the Information Technology Task Force (ITTF) a statement of willingness to grant a license under such rights that they hold on reasonable and non-discriminatory terms and conditions to applicants desiring to obtain such a license. Information regarding such patents can be obtained from the following organizations. The table summarizes the formal patent statements received and indicates the parts of the standard to which the statement applies. Three "N"s in a row corresponding to a company means that the statement from the company did not mention any part. The list includes all organizations that have submitted informal patent statements. However, if no "X" is present, no formal patent statement has yet been received from that organization. Table I-1 -- List of companies supplying patent statements
Download 2.79 Mb. Share with your friends:
|