Enhancement of supplemental enhancement information signaling in video bitstream
By introducing the SEI RBSP header and a new NAL unit type, the problem of large-size SEI message signaling was solved, ensuring the accuracy of the necessity indication of SEI messages and improving the efficiency and reliability of the video encoding and decoding process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- DOUYIN CO LTD
- Filing Date
- 2024-10-09
- Publication Date
- 2026-05-19
AI Technical Summary
Existing SEI message signaling methods cannot effectively handle large SEI messages, and the use of the REQ_SEI_NUT NAL unit fails to accurately indicate the necessity of the subsequent SEI NAL unit.
The SEI RBSP header is introduced to carry relevant information about the SEI message, including necessity indication, type and size information, and a new NAL unit type, such as NEW_SEI_NUT, is defined to accommodate the SEI RBSP, ensuring the effective transmission and parsing of the SEI message.
Effective signaling for large-size SEI messages was achieved, ensuring the accuracy of necessity indication for SEI messages and improving the efficiency and reliability of the video encoding and decoding process.
Smart Images

Figure CN122070697A_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims priority and rights to U.S. Provisional Patent Application 63 / 589,720, filed October 12, 2023. The aforementioned patent application is incorporated herein by reference in its entirety. Technical Field
[0003] This patent document relates to the generation, storage, and use of digital audio and video media information in file formats. Background Technology
[0004] Digital video accounts for the largest share of bandwidth used on the internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demand for digital video is likely to continue to grow. Summary of the Invention
[0005] The first aspect relates to a method for processing video data, comprising: determining one or more bytes of data from a Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header, wherein the SEI RBSP header is included in the SEI RBSP and precedes one or more SEI messages carried in the SEI RBSP; and performing a conversion between visual media data and a bitstream based on the SEI RBSP header.
[0006] The second aspect relates to an apparatus for processing video data, including a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform any of the preceding aspects.
[0007] The third aspect relates to a non-transitory computer-readable medium including a computer program product for use by a video codec device, the computer program product including computer-executable instructions stored on the non-transitory computer-readable medium such that when the computer-executable instructions are executed by a processor, the video codec device performs the method of any of the preceding aspects.
[0008] The fourth aspect relates to a non-transitory computer-readable recording medium storing a bitstream of video generated by a method performed by a video processing apparatus, wherein the method includes: determining one or more bytes of data from a Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header, wherein the SEI RBSP header is included in the SEI RBSP and preceding one or more SEI messages carried in the SEI RBSP; and generating a bitstream based on the determination.
[0009] The fifth aspect relates to a method for storing a bitstream of video, comprising: determining one or more bytes of data from a supplementary enhancement information (SEI) raw byte sequence payload (RBSP) header, wherein the SEI RBSP header is included in the SEI RBSP and preceding one or more SEI messages carried in the SEI RBSP; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.
[0010] For clarity, any of the embodiments described above may be combined with one or more other embodiments described above to create new embodiments within the scope of this disclosure.
[0011] These and other features will become clearer when viewed in conjunction with the accompanying drawings and claims in the following detailed description. Attached Figure Description
[0012] To gain a more complete understanding of this disclosure, reference is now made to the following brief description, taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals denote like parts.
[0013] Figure 1 This is a block diagram illustrating an example video processing system.
[0014] Figure 2 This is a block diagram of an example video processing device.
[0015] Figure 3 This is a flowchart of an example method for video processing.
[0016] Figure 4 This is a block diagram illustrating an example video codec system.
[0017] Figure 5 This is a block diagram showing an example encoder.
[0018] Figure 6 This is a block diagram showing an example decoder.
[0019] Figure 7 This is a schematic diagram of an example encoder. Detailed Implementation
[0020] First, it should be understood that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods can be implemented using any number of techniques, whether currently known or yet to be developed. This disclosure should not in any way limit itself to the illustrative implementations, drawings, and techniques shown below, including the exemplary designs and implementations shown and described herein, but rather to modifications that can be made within the scope of the appended claims and their equivalents.
[0021] Chapter headings are used in this document for ease of understanding and not to limit the applicability of the techniques and embodiments disclosed in each chapter to that chapter only. Furthermore, H.266 terminology is used in some descriptions merely for ease of understanding and not to limit the scope of the disclosed techniques. Therefore, the techniques described herein are also applicable to other video codec protocols and designs. In this document, editorial changes relative to the Multi-Functional Video Codec (VVC) specification and / or the SEI Message (VSEI) standard for encoding and decoding video bitstreams are indicated in the text by bold italics (indicating deleted text) and bold text (indicating added text).
[0022] 1. Preliminary Discussion
[0023] This document relates to image / video codec techniques. Specifically, this disclosure relates to signaling enhancement of Supplemental Enhancement Information (SEI) in video bitstreams. These ideas can be applied individually or in various combinations for video bitstreams encoded and decoded by any codec, such as the VVC standard, the High Efficiency Video Codec (HEVC) standard, the Advanced Video Codec (AVC) standard, or other standards.
[0024] 2. Abbreviation
[0025] Adaptive Parameter Set (APS), Access Unit (AU), Codec Layer Video Sequence (CLVS), Codec Layer Video Sequence Start (CLVSS), Cyclic Redundancy Check (CRC), Codec Video Sequence (CVS), Finite Impulse Response (FIR), Intra-Frame Random Access Point (IRAP), Network Abstraction Layer (NAL), Picture Parameter Set (PPS), Picture Unit (PU), Random Access Skip Before (RASL) Picture, Raw Byte Sequence Payload (RBSP), Supplemental Enhancement Information (SEI), Stepped Temporal Sublayer Access (STSA), Video Codec Layer (VCL), Multifunctional Supplemental Enhancement Information (VSEI) described in Recommendation ITU-T H.274 | ISO / IEC 23002-7, Video Availability Information (VUI), and Multifunctional Video Codec (VVC) described in Recommendation ITU-T H.266 | ISO / IEC 23090-3.
[0026] 3. Further discussion
[0027] 3.1 Video Coding and Decoding Standards
[0028] Video coding standards have evolved primarily through the development of standards by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) and the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC). ITU-T developed the H.261 and H.263 standards, while ISO / IEC developed the Moving Picture Experts Group (MPEG)-1 and MPEG-4 Vision standards. The two organizations jointly developed the H.262 / MPEG-2 video standard, the H.264 / MPEG-4 Advanced Video Coding (AVC) standard, and the H.265 / High Efficiency Video Coding (HEVC) standard [1]. Starting with H.262, video coding standards are based on a hybrid video coding structure, which utilizes temporal prediction plus transform coding. The Multi-Functional Video Coding (VVC) standard (ITU-T H.266 | ISO / IEC 23090-3) [2] and the related Multi-Functional Supplemental Enhancement Information (VSEI) standard (ITU-T H.274 | ISO / IEC 23002-7) [3] are designed for use in the widest range of applications, including simple uses such as television broadcasting, video conferencing or playback from storage media, as well as more advanced use cases such as adaptive bitrate streaming, video region extraction, synthesis and merging of content from multiple encoded video bitstreams, multi-view video, scalable layered coding and decoding and viewport adaptive 360° immersive media.
[0029] 3.2 General SEI messages and SEI messages in VVC, HEVC, and AVC
[0030] SEI messages assist in processes related to decoding, display, or other purposes. However, SEI messages are not essential for constructing luma or chroma samples during the decoding process. Standard-compliant decoders do not need to process this information to achieve output order consistency. Some SEI messages are necessary for checking bitstream consistency and output timing decoder consistency. Other SEI messages are not necessary for checking bitstream consistency.
[0031] The syntax and semantics of the SEI message payload are specified in Annex D (for VVC, HEVC and AVC) and in ITU-T H.274 | ISO / IEC 23002-7.
[0032] In VVC, HEVC, and AVC, an SEI message includes some syntax elements preceding the SEI payload and the SEI payload itself. For simplicity, the syntax elements preceding the SEI payload in an SEI message are referred to as the SEI Message Header (SMH). One or more SEI messages are contained within an SEI NAL unit. Each NAL unit includes a NAL unit header, followed by the RBSP syntax for the specific type of NAL unit.
[0033] In VVC and HEVC, two NAL unit types are defined for SEI NAL units: one for prefix SEI NAL units and the other for suffix SEI NAL units. In VVC, the NAL unit types (NUTs) for prefix and suffix SEI NAL units are values 23 and 24 (of nal_unit_type), respectively, and are named Prefix NAL Unit Type (PREFIX_SEI_NUT) and Suffix SEI NAL Unit Type (SUFFIX_SEI_NUT), respectively. In HEVC, the NAL unit types for prefix and suffix SEI NAL units are values 39 and 40 (of nal_unit_type), and are also named PREFIX_SEI_NUT and SUFFIX_SEI_NUT, respectively.
[0034] In AVC, only one NAL unit type is specified for SEI NAL units. The NAL unit used for SEI NAL units in VVC is value 6 (nal_unit_type), and is unnamed.
[0035] The SEI RBSP syntax and semantics are as follows (the same applies to VVC, HEVC, and AVC):
[0036]
[0037] Supplemental Enhancement Information (SEI) contains information unnecessary for the samples of the encoded / decoded image decoded from the VCL NAL unit. An SEI RBSP contains one or more SEI messages.
[0038] The general SEI message syntax and semantics in VVC are as follows (technically the same as HEVC and AVC, but slightly different in editing):
[0039]
[0040] Each SEI message consists of variables specifying the SEI message payload type (payloadType) and size (payloadSize). The SEI message payload is specified in Appendix D. The derived SEI message payload size (payloadSize) is specified in bytes and must be equal to the number of RBSP bytes in the SEI message payload.
[0041] Note - The NAL unit byte sequence containing the SEI message may include one or more anti-spoofing bytes (represented by the emulation_prevention_three_byte syntax element). Since the SEI message payload size is specified in RBSP bytes, the number of anti-spoofing bytes is not included in the SEI payload size payloadSize.
[0042] payload_type_byte is the byte representing the payload type of the SEI message.
[0043] payload_size_byte is the size of the SEI message payload in bytes.
[0044] 3.3 Signaling for Large-Size SEI Messages
[0045] The Joint Video Exploration Team (JVET) - AF0148-v1 (publicly available at: https: / / www.jvet-experts.org / doc_end_user / documents / 32_Hannover / wg11 / JVET-AF0148-v1.zip) has proposed a complementary approach for large SEI messages, significantly reducing the number of bits required to transmit the SEI payload size via signaling for large SEI messages. For example, a large SEI message reportedly containing 64kB of data in its payload would require 256 bytes to transmit the payload size via signaling.
[0046] The proposed general SEI message syntax and semantics are as follows:
[0047]
[0048] Each large SEI message consists of variables specifying the type (payloadType) and size (payloadSize) of the large SEI message payload. The large SEI message payload is specified in Appendix D. The derived large SEI message payload size (payloadSize) is specified in bytes and must be equal to the number of RBSP bytes in the large SEI message payload.
[0049] Note - The NAL unit byte sequence containing the large SEI message may include one or more anti-spoofing bytes (represented by the emulation_prevention_three_byte syntax element). Since the payload size of the large SEI message is specified in RBSP bytes, the number of anti-spoofing bytes is not included in the payloadSize of the large SEI payload.
[0050] `lsei_position` indicates whether a SEI message corresponds to either `PREFIX_SEI_NUT` or `SUFFIX_SEI_NUT`. `lsei_position` equal to 0 indicates that the SEI message is treated as `PREFIX_SEI_NUT`. `lsei_position` equal to 1 indicates that the SEI message is treated as `SUFFIX_SEI_NUT`. Values 3 and 4 of `lsei_position` are reserved for future use and must be ignored.
[0051] `lsei_relevance` indicates the relevance of the SEI message to the target application. `lsei_relevance` ranges from 0 to 3, with 0 being the least relevant and 3 being the most relevant.
[0052] Note: The relevance of SEI messages is arbitrarily determined, and their use will be specified by the target application.
[0053] lsei_reserved is reserved for future use and must be ignored.
[0054] `lsei_payload_type_byte` is a byte representing the payload type of the large SEI message. `payloadType = lsei_payload_type_byte`.
[0055] payload_size_16bits is the payload size (in bits) of a large SEI message. payloadSize = payload_size_16bits.
[0056] 3.4 SEI NAL Units Required for the Application
[0057] JVET-AF0149-v1 (publicly available at: https: / / www.jvet-experts.org / doc_end_user / documents / 32_Hannover / wg11 / JVET-AF0149-v1.zip) proposes a method for signaling application-required SEI messages maintained in a bitstream. This method involves defining a new NAL unit type for VVC, where the value of nal_unit_type is equal to 26 (and named REQ_SEI_NUT), with the following semantics: when a REQ_SEI_NUT NAL unit exists, either PREFIX_SEI_NUT or SUFFIX_SEI_NUT immediately following it is considered essential to the application.
[0058] 4. The technical problem solved by the disclosed technical solution
[0059] The example design of the signaling for SEI messages has the following problems.
[0060] First, the method in JVET-AF0148-v1 does not support SEI messages with payload sizes greater than 64 kilobytes (KB).
[0061] Second, in JVET-AF0149-v1, when a REQ_SEI_NUT NAL unit exists, the immediately following PREFIX_SEI_NUT or SUFFIX_SEI_NUT is considered essential to the application. However, this makes no sense because it requires carrying one or more SEI messages (in the SEI NAL unit where nal_unit_type equals REQ_SEI_NUT) simply to indicate that the immediately following SEI NAL unit where nal_unit_type equals PREFIX_SEI_NUT or SUFFIX_SEI_NUT is considered essential (or necessary) to the application.
[0062] 5. List of solutions and implementation examples
[0063] To address the aforementioned problems, methods outlined below are disclosed. These aspects should be considered as examples for interpreting general concepts, and not interpreted in a narrow sense. Furthermore, these examples can be applied individually or in any combination.
[0064] 1) In one example, one or more bytes of data are included in the SEI RBSP and precede one or more SEI messages carried in the SEI RBSP. For convenience, this one or more bytes of data is referred to as the SEI RBSP header.
[0065] a. In one example, the SEI RBSP header includes information applicable to all SEI messages carried in the SEI RBSP (i.e., all SEI messages carried in the SEI NAL unit).
[0066] i. Alternatively, in one example, the SEI RBSP header includes information applicable to at least one SEI message carried in the SEI NAL unit.
[0067] b. In one example, the SEI RBSP header includes an indication of whether all SEI messages carried in the SEI NAL unit are considered, for example, essential (or necessary) to the application by an encoder or content provider.
[0068] i. Alternatively, in one example, the SEI RBSP header includes an indication of whether all SEI messages carried in the SEI NAL unit can be considered, for example, essential (or necessary) to the application by an encoder or content provider.
[0069] ii. Alternatively, in one example, the SEI RBSP header includes an indication of whether at least one SEI message carried in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) for the application.
[0070] iii. Alternatively, in one example, the SEI RBSP header includes an indication of whether at least one SEI message carried in the SEI NAL unit can be considered by, for example, an encoder or content provider to be essential (or necessary) for the application.
[0071] iv. In one example, the indication is a 1-bit flag with a first value and a second value, where the first value (e.g., 1) indicates that the SEI message contained in the SEI RBSP is considered necessary, and the second value (e.g., 0) indicates that the SEI message contained in the SEI RBSP is not considered necessary.
[0072] v. In one example, the indication is a 2-bit syntax element with a first value, a second value, and a third value, where the first value indicates that the SEI message contained in the SEI RBSP is considered necessary, the second value indicates that the SEI message contained in the SEI RBSP is considered unnecessary, and the third value indicates that the necessity of the SEI message contained in the SEI RBSP is not determined.
[0073] c. In one example, the SEI RBSP header includes an indication of whether the SEI NAL cell is a prefix SEI NAL cell or a suffix SEI NAL cell.
[0074] i. In one example, it is specified that the prefix SEI NAL unit must precede the first VCL NAL unit among all VCLNAL units associated with the SEI NAL unit, and be the same as the SEI NAL unit in VVC or HEVC whose nal_unit_type is equal to PREFIX_SEI_NUT.
[0075] ii. In one example, it is specified that the suffix SEI NAL unit must be after the last VCL NAL unit among all VCLNAL units associated with the SEI NAL unit, and be the same as the SEI NAL unit in VVC or HEVC whose nal_unit_type is equal to SUFFIX_SEI_NUT.
[0076] d. In one example, the SEI RBSP header includes a type length indicator that indicates the length (in bits) of the SEI payload type syntax element (e.g., named payload_type) of each SEI message contained in the SEI NAL unit.
[0077] i. In one example, the type length indicator is a 1-bit flag.
[0078] 1. In one example, a 1-bit flag equal to 0 indicates a length of 8 bits, and a 1-bit flag equal to 0 indicates a length of 16 bits.
[0079] 2. In one example, a 1-bit flag equal to 0 indicates a length of 8 bits, and a 1-bit flag equal to 0 indicates a length of 10 bits.
[0080] ii. In one example, the type length indicator is a 2-bit syntax element.
[0081] 1. In one example, a 2-bit syntax element is not allowed to be equal to 0 (therefore, there is always at least one bit that is equal to 1).
[0082] iii. In one example, the type length indicator is an N-bit syntax element, where N is an integer greater than 2.
[0083] e. In one example, the SEI RBSP header includes a size length indicator that indicates the length (in bits) of the SEI payload size syntax element (e.g., named payload_size) of each SEI message contained in the SEI NAL cell.
[0084] i. In one example, the type length indicator is a 2-bit syntax element.
[0085] 1. In one example, 2-bit syntax elements equal to 0, 1, 2, and 3 indicate lengths of 8, 16, 24, and 32 bits, respectively.
[0086] 2. In one example, 2-bit syntax elements equal to 0, 1, 2, and 3 indicate lengths of 4, 8, 16, and 24 bits, respectively.
[0087] 3. In one example, a 2-bit syntax element is not allowed to be equal to 0 (therefore, there is always at least one bit that is equal to 1).
[0088] a. In one example, 2-bit syntax elements equal to 1, 2, and 3 indicate lengths of 8, 16, and 24 bits, respectively.
[0089] b. In one example, 2-bit syntax elements equal to 1, 2, and 3 indicate lengths of 8, 16, and 32 bits, respectively.
[0090] ii. In one example, the type length indicator is an N-bit syntax element, where N is an integer greater than 2.
[0091] 1. In one example, N-bit syntax elements are not allowed to be equal to 0 (therefore, there is always at least one bit equal to 1).
[0092] f. In one example, the SEI RBSP header includes one or more reserved bits.
[0093] i. In one example, one or more reserved bits are equal to 0.
[0094] ii. In one example, one or more reserved bits are equal to 1.
[0095] iii. In one example, one of the one or more reserved bits is equal to 1, and the remaining one or more reserved bits are equal to 0.
[0096] iv. In one example, the reserved bits precede the type length indicator and the size length indicator.
[0097] v. In one example, reserve bits after the type length indicator and the size length indicator.
[0098] g. In one example, the SEI RBSP header always includes at least one bit equal to 1.
[0099] 2) In one example, in the SEI message header (which contains one or more bytes of data preceding the SEI payload in the SEI message), a syntax element indicating the SEI payload type (e.g., named payload_type) is u(v) encoded and decoded, and the length of the syntax element (in bits) is indicated by the type length indicator in the SEI RBSP header.
[0100] 3) In one example, in the SEI message header, a syntax element indicating the SEI payload size (e.g., named payload_size) is encoded and decoded by u(v), and the length of the syntax element (in bits) is indicated by the size length indicator in the SEI RBSP header.
[0101] 4) In one example, the type length indicator is included in the SEI message header instead of the SEI RBSP header, and the syntax element in the SEI message header that indicates the SEI payload type (e.g., named payload_size) is encoded and decoded by u(v), and the length of the syntax element (in bits) is indicated by the type length indicator in the SEI message header.
[0102] 5) In one example, the size length indicator is included in the SEI message header instead of the SEI RBSP header, and the syntax element in the SEI message header that indicates the SEI payload size (e.g., named payload_size) is encoded and decoded by u(v), and the length of the syntax element (in bits) is indicated by the type length indicator in the SEI message header.
[0103] 6) In one example, no type length indicator is included in the SEI message header, and no type length indicator is included in the SEI RBSP header, and the syntax element in the SEI message header indicating the SEI payload type (e.g., named payload_type) is encoded and decoded by ue(v).
[0104] 7) In one example, no size length indication is included in the SEI message header, and no size length indication is included in the SEI RBSP header, and the syntax element in the SEI message header that indicates the SEI payload size (e.g., named payload_size) is encoded and decoded by ue(v).
[0105] 8) In one example, in the SEI message header, after the syntax element indicating the SEI payload type (e.g., named payload_type) and the syntax element indicating the SEI payload size (e.g., named payload_size), there is a byte alignment check, followed by byte alignment bits equal to 0, until it is byte aligned.
[0106] 9) In one example, for VVC, a new NAL unit type (e.g., nal_unit_type with a value of 26, e.g., named NEW_SEI_NUT) is specified for SEI NAL units containing SEI RBSPs, where the SEI RBSP has an SEI RBSP header and / or SEI message header as specified in one of the methods described above.
[0107] a. Alternatively, in one example, for VVC, two new NAL unit types (e.g., nal_unit_type values of 26 and 27, e.g., named PREFIX_NEW_SEI_NUT and SUFFIX_NEW_SEI_NUT) are specified for SEI NAL units containing SEI RBSPs, where the SEI RBSPs have the SEI RBSP syntax and SEI message syntax currently specified in VVC.
[0108] i. In one example, it is specified that the SEI NAL unit with nal_unit_type equal to PREFIX_NEW_SEI_NUT must be a prefixed SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to PREFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0109] ii. In one example, it is specified that the SEI NAL unit with nal_unit_type equal to SUFFIX_NEW_SEI_NUT must be a suffix SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to SUFFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0110] 10) In one example, for HEVC, a new NAL unit type (e.g., nal_unit_type with a value of 41, e.g., named NEW_SEI_NUT) is specified for SEI NAL units containing SEI RBSPs, where the SEI RBSP has an SEI RBSP header and / or SEI message header as specified in one of the methods described above.
[0111] a. Alternatively, in one example, for HEVC, two new NAL unit types (e.g., nal_unit_type values 41 and 42, e.g., named PREFIX_NEW_SEI_NUT and SUFFIX_NEW_SEI_NUT) are specified for SEI NAL units containing SEI RBSPs, where the SEI RBSPs have the SEI RBSP syntax and SEI message syntax currently specified in HEVC.
[0112] i. In one example, it is specified that the SEI NAL unit with nal_unit_type equal to PREFIX_NEW_SEI_NUT must be a prefixed SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to PREFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0113] ii. In one example, it is specified that the SEI NAL unit with nal_unit_type equal to SUFFIX_NEW_SEI_NUT must be a suffix SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to SUFFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0114] 11) In one example, for AVC, a new NAL unit type (e.g., nal_unit_type with a value of 17, e.g., named NEW_SEI_NUT) is specified for SEI NAL units containing SEI RBSPs, where the SEI RBSP has an SEI RBSP header and / or SEI message header as specified in one of the methods described above.
[0115] 12) In one example, for new video codec standards other than VVC, HEVC, and AVC, a specific NAL unit type value of nal_unit_type (e.g., named SEI_NUT) is specified for SEI NAL units containing SEI RBSPs, where the SEI RBSPs have SEI RBSP headers and / or SEI message headers as specified in one of the methods described above, and no other NAL unit types are specified for SEI NAL units.
[0116] 13) In one example, an indication is included in the Real-Time Transport Protocol (RTP) packet payload structure to indicate that the SEI message contained in one or more specific SEI NAL units contained in the RTP packet is considered by, for example, by the sender or content provider to be essential (or necessary) to the application.
[0117] 6. Examples
[0118] The following are some example implementations of the aspects outlined in Section 5 of the previous article.
[0119] Most of the relevant sections that have been added or modified are shown in bold, and some of the deleted sections are shown in bold italics. There may be some other changes that are editable in nature and therefore not indicated.
[0120] However, in embodiments other than Example 1, all text is new and is not highlighted.
[0121] The first embodiment is a specification for the new NAL unit type.
[0122] Other embodiments are for SEI RBSP syntax including SEI RBSP headers and SEI message syntax including SEI message headers.
[0123] 6.1 Example 1
[0124] This embodiment is a specification for the new NAL unit type. ...
[0126] Table 5 - NAL Unit Type Codes and NAL Unit Type Classes
[0127] ...
[0129] 6.2 Example 2
[0130] In this embodiment, the SEI RBSP header is one byte, the SEI message header contains only two syntax elements for payload type and payload size, and the lengths of the payload type field and payload size field are always integer multiples of bytes.
[0131]
[0132] Supplemental Enhancement Information (SEI) contains information unnecessary for the samples of the encoded / decoded image decoded from the VCL NAL unit. An SEI RBSP contains one or more SEI messages.
[0133] A sei_necessary_flag value of 1 indicates that the SEI message contained in the SEI RBSP is considered necessary. A sei_necessary_flag value of 0 indicates that the SEI message contained in the SEI RBSP is not considered necessary.
[0134] A `sei_prefix_or_suffix_flag` value of 1 indicates that the SEI NAL cell containing the SEI RBSP is a prefix SEI NAL cell, which must precede the first VCL NAL cell among all VCL NAL cells associated with the SEI NAL cell. A `sei_prefix_or_suffix_flag` value of 0 indicates that the SEI NAL cell containing the SEI RBSP is a suffix SEI NAL cell, which must follow the last VCL NAL cell among all VCL NAL cells associated with the SEI NAL cell.
[0135] In a bitstream conforming to this version of the specification, sei_reserved_one_3bits must be equal to 7. Values of sei_reserved_one_3bits less than 7 are reserved for future use by ITU-T | ISO / IEC. The decoder must also allow values of sei_reserved_one_3bits less than 7 to appear in the bitstream and must ignore the value of sei_reserved_one_3bits.
[0136] `sei_payload_type_len_flag` specifies the length of the `payload_type` syntax element in the `sei_v2_message()` syntax structure contained in the SEI RBSP. The length of the `payload_type` syntax element is equal to (1 + `sei_payload_type_len_flag`). 8 bits.
[0137] `sei_payload_size_len` specifies the length of the `payload_size` syntax element in the `sei_v2_message()` syntax structure contained in the SEI RBSP. The length of the `payload_size` syntax element is equal to (1 + `sei_payload_size_len`). 8 bits.
[0138]
[0139] Each SEI message consists of variables specifying the SEI message payload type (which is set to be equal to payload_type) and size (which is set to be equal to payload_size). The SEI message payload is specified in Appendix D or VSEI. The derived SEI message payload size payloadSize is specified in bytes and must be equal to the number of RBSP bytes in the SEI message payload.
[0140] Note - The NAL unit byte sequence containing the SEI message may include one or more anti-spoofing bytes (represented by the emulation_prevention_three_byte syntax element). Since the SEI message payload size is specified in RBSP bytes, the number of anti-spoofing bytes is not included in the SEI payload size payloadSize.
[0141] The payload_type specifies the payload type of the SEI message. The length of the payload_type syntax element is (1 + sei_payload_type_len_flag). 8 bits.
[0142] The payload_size specifies the size of the SEI message payload in bytes. The length of the payload_size syntax element is (1 + sei_payload_size_len). 8 bits.
[0143] 6.3 Example 3
[0144] In this embodiment, the SEI RBSP header is one byte, the SEI message header contains only two syntax elements for payload type and payload size, and one or both of the lengths of the payload type field and the payload size field are not always integer multiples of bytes, so there is byte alignment syntax after the payload size field in the SEI message syntax.
[0145]
[0146] Supplemental Enhancement Information (SEI) contains information unnecessary for the samples of the encoded / decoded image decoded from the VCL NAL unit. An SEI RBSP contains one or more SEI messages.
[0147] A sei_necessary_flag value of 1 indicates that the SEI message contained in the SEI RBSP is considered necessary. A sei_necessary_flag value of 0 indicates that the SEI message contained in the SEI RBSP is not considered necessary.
[0148] A `sei_prefix_or_suffix_flag` value of 1 indicates that the SEI NAL cell containing the SEI RBSP is a prefix SEI NAL cell, which must precede the first VCL NAL cell among all VCL NAL cells associated with the SEI NAL cell. A `sei_prefix_or_suffix_flag` value of 0 indicates that the SEI NAL cell containing the SEI RBSP is a suffix SEI NAL cell, which must follow the last VCL NAL cell among all VCL NAL cells associated with the SEI NAL cell.
[0149] `sei_payload_type_len_plus1` specifies the length of the `payload_type` syntax element in the `sei_v2_message()` syntax structure contained in the SEI RBSP. The value of `sei_payload_type_len_plus1` should not be equal to 0. The length of the `payload_type` syntax element is equal to `sei_payload_type_len_plus1`. 2 + 4 bits.
[0150] sei_payload_size_len specifies the length of the payload_size syntax element in the sei_v2_message() syntax structure contained in the SEI RBSP.
[0151] The variable PayloadSizeLen is set to equal to (1 + sei_payload_size_len). 8.
[0152] Alternatively, 1) when sei_payload_size_len equals 0, the variable PayloadSizeLen is set to equal 4; 2) when sei_payload_size_len equals 1, the variable PayloadSizeLen is set to equal 8; 3) when sei_payload_size_len equals 2, the variable PayloadSizeLen is set to equal 16; and 4) when sei_payload_size_len equals 3, the variable PayloadSizeLen is set to equal 24.
[0153] In bitstreams conforming to this version of the specification, sei_reserved_zero_2bits must be equal to 0. Values greater than 0 in sei_reserved_zero_2bits are reserved for future use by ITU-T | ISO / IEC. The decoder must also allow values greater than 0 in sei_reserved_zero_2bits to appear in the bitstream and must ignore the value of sei_reserved_zero_2bits.
[0154]
[0155] Each SEI message consists of variables specifying the SEI message payload type (which is set to be equal to payload_type) and size (which is set to be equal to payload_size). The SEI message payload is specified in Appendix D or VSEI. The derived SEI message payload size payloadSize is specified in bytes and must be equal to the number of RBSP bytes in the SEI message payload.
[0156] Note - The NAL unit byte sequence containing the SEI message may include one or more anti-spoofing bytes (represented by the emulation_prevention_three_byte syntax element). Since the SEI message payload size is specified in RBSP bytes, the number of anti-spoofing bytes is not included in the SEI payload size payloadSize.
[0157] The payload_type specifies the payload type of the SEI message. The length of the payload_type syntax element is sei_payload_type_len_plus1. 2 + 4 bits.
[0158] The payload_size specifies the size of the SEI message payload (in bytes). The length of the payload_size syntax element is PayloadSizeLen bits.
[0159] 6.4 Example 4
[0160] In this embodiment, the SEI RBSP header is one byte. In addition to the two syntax elements for payload type and payload size, the SEI message header also contains one byte. The SEI RBSP header always has at least one bit equal to 1, and the lengths of the payload type field and payload size field are always integer multiples of bytes.
[0161]
[0162] Supplemental Enhancement Information (SEI) contains information unnecessary for the samples of the encoded / decoded image decoded from the VCL NAL unit. An SEI RBSP contains one or more SEI messages.
[0163] A sei_necessary_flag value of 1 indicates that the SEI message contained in the SEI RBSP is considered necessary. A sei_necessary_flag value of 0 indicates that the SEI message contained in the SEI RBSP is not considered necessary.
[0164] A `sei_prefix_or_suffix_flag` value of 1 indicates that the SEI NAL cell containing the SEI RBSP is a prefix SEI NAL cell, which must precede the first VCL NAL cell among all VCL NAL cells associated with the SEI NAL cell. A `sei_prefix_or_suffix_flag` value of 0 indicates that the SEI NAL cell containing the SEI RBSP is a suffix SEI NAL cell, which must follow the last VCL NAL cell among all VCL NAL cells associated with the SEI NAL cell.
[0165] sei_bit_equal_to_one must be equal to 1.
[0166] The `sei_rbsp_reserved_zero_5bits` parameter must be equal to 0 in a bitstream conforming to this version of the specification. Values greater than 0 in `sei_rbsp_reserved_zero_5bits` are reserved for future use by ITU-T | ISO / IEC. The decoder must also allow values greater than 0 in `sei_rbsp_reserved_zero_5bits` to appear in the bitstream and must ignore the value of `sei_rbsp_reserved_zero_5bits`.
[0167]
[0168] Each SEI message consists of variables specifying the SEI message payload type (which is set to be equal to payload_type) and size (which is set to be equal to payload_size). The SEI message payload is specified in Appendix D or VSEI. The derived SEI message payload size payloadSize is specified in bytes and must be equal to the number of RBSP bytes in the SEI message payload.
[0169] Note - The NAL unit byte sequence containing the SEI message may include one or more anti-spoofing bytes (represented by the emulation_prevention_three_byte syntax element). Since the SEI message payload size is specified in RBSP bytes, the number of anti-spoofing bytes is not included in the SEI payload size payloadSize.
[0170] The `sei_msg_reserved_zero_5bits` parameter must be equal to 0 in a bitstream conforming to this version of the specification. Values greater than 0 in `sei_msg_reserved_zero_5bits` are reserved for future use by ITU-T | ISO / IEC. The decoder must also allow values greater than 0 in `sei_msg_reserved_zero_5bits` to appear in the bitstream and must ignore the value of `sei_msg_reserved_zero_5bits`.
[0171] `sei_payload_type_len_flag` specifies the length of the `payload_type` syntax element in the `sei_v2_message()` syntax structure. The length of the `payload_type` syntax element is equal to (1 + `sei_payload_type_len_flag`). 8 bits.
[0172] `sei_payload_size_len` specifies the length of the `payload_size` syntax element in the `sei_v2_message()` syntax structure. The length of the `payload_size` syntax element is equal to (1 + `sei_payload_size_len`). 8 bits.
[0173] The payload_type specifies the payload type of the SEI message. The length of the payload_type syntax element is (1 + sei_payload_type_len_flag). 8 bits.
[0174] The payload_size specifies the size of the SEI message payload in bytes. The length of the payload_size syntax element is (1 + sei_payload_size_len). 8 bits.
[0175] 6.5 Example 5
[0176] The SEI RBSP header consists of one or more bytes, always equal to 1 bit; the SEI message header consists of one or more bytes; and the lengths of the payload type and payload size fields are not always integer multiples of bytes. Therefore, byte alignment syntax follows the payload size field in the SEI message syntax. The semantics are similar to those described above.
[0177]
[0178]
[0179] 6.6 Example 6
[0180] It does not have an SEI RBSP header of one or more bytes that is always equal to 1 bit, an SEI message header of one or more bytes, and the length of the payload type and payload size fields is always an integer multiple of bytes. The semantics are similar to those described above.
[0181]
[0182]
[0183] 6.7 Example 7
[0184] The SEI RBSP header, which does not always have a single bit equal to 1 (one or more bytes), the SEI message header, which has one or more bytes, and the payload type and payload size fields, whose lengths are not always integer multiples of bytes, are not present. Therefore, there is byte alignment syntax following the payload size field in the SEI message syntax. The semantics are similar to those described above.
[0185]
[0186]
[0187] 6.8 Example 8
[0188] One or more bytes of SEI RBSP header, with or without a bit that is always equal to 1, 0 bytes of SEI message header, payload type and payload size fields for ue(v) encoding / decoding, and byte alignment syntax following the payload size field in the SEI message syntax. The semantics are similar to those described above.
[0189]
[0190]
[0191] 6.9 Example 9
[0192] One or more bytes of SEI RBSP header, with or without a bit that is always equal to 1, one or more bytes of SEI message header, payload type and payload size fields for ue(v) encoding / decoding, and byte alignment syntax following the payload size field in the SEI message syntax. The semantics are similar to those described above.
[0193]
[0194]
[0195] 7. References
[0196] [1] ITU-T and ISO / IEC, “High efficiency video coding”, Rec. ITU-TH.265 | ISO / IEC 23008-2 (in force edition).
[0197] [2] ITU-T and ISO / IEC, “Versatile Video Coding”, Rec. ITU-T H.266 | ISO / IEC 23090-3.
[0198] [3] ITU-T and ISO / IEC, “Versatile Supplemental EnhancementInformation Messages for Coded Video Bitstreams”, Rec. ITU-T Rec. H.274 | ISO / IEC 23002-7.
[0199] Figure 1 This is a block diagram illustrating an example video processing system 4000 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 4000. System 4000 may include an input 4002 for receiving video content. The video content may be received in a raw or uncompressed format, such as 8 or 10-bit multi-component pixel values, or it may be received in a compressed or encoded format. Input 4002 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, Passive Optical Network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.
[0200] System 4000 may include an encoding component 4004 capable of implementing the various encoding / decoding or encoding methods described in this document. Encoding component 4004 can reduce the average bit rate from the video input 4002 to the output of encoding component 4004 to produce an encoded representation of the video. Encoding techniques are therefore sometimes referred to as video compression or video transcoding techniques. The output of encoding component 4004 may be stored or transmitted via a communication connection such as that represented by component 4006. The bitstream (or encoded) representation of the video received at input 4002, whether stored or communicated, may be used by component 4008 to generate pixel values or displayable video that is sent to display interface 4010. The process of generating user-visible video from the bitstream representation is sometimes referred to as video decompression. Furthermore, although some video processing operations are referred to as “encoding” operations or tools, it is understood that encoding / decoding tools or operations are used at the encoder, and the corresponding decoding tools or operations that inversely reproduce the encoded result will be performed by the decoder.
[0201] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), or DisplayPort. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect (PCI), Integrated Drive Electronics (IDE), etc. The technologies described in this document can be found in a variety of electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.
[0202] Figure 2 This is a block diagram of an example video processing apparatus 4100. Apparatus 4100 can be used to implement one or more methods described herein. Apparatus 4100 can be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, etc. Apparatus 4100 may include one or more processors 4102, one or more memories 4104, and video processing circuitry 4106. The processors 4102(s) may be configured to implement one or more methods described herein. The memories 4104(s) may be used to store data and code for implementing the methods and techniques described herein. The video processing circuitry 4106 may be used to implement some of the techniques described herein in hardware circuitry. In some embodiments, the video processing circuitry 4106 may be at least partially included in the processor 4102, for example, a graphics coprocessor.
[0203] Figure 3This is a flowchart of an example method 4200 for video processing. In step 4202, method 4200 determines one or more bytes of data from the Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header, wherein the SEI RBSP header is included in the SEI RBSP and precedes one or more SEI messages carried within the SEI RBSP. In step 4204, a conversion between visual media data and a bitstream is performed based on the SEI RBSP header. The conversion may include encoding at the encoder, decoding at the decoder, or a combination thereof.
[0204] It should be noted that method 4200 can be implemented in an apparatus for processing video data, including a processor and a non-transitory memory having instructions thereon, such as a video encoder 4400, a video decoder 4500, and / or an encoder 4600. In this case, the instructions, when executed by the processor, cause the processor to perform method 4200. Furthermore, method 4200 can be executed by a non-transitory computer-readable medium including a computer program product for use by a video codec device. The computer program product includes computer-executable instructions stored on the non-transitory computer-readable medium, causing the video codec device to perform method 4200 when executed by a processor.
[0205] Figure 4 This is a block diagram illustrating an example video encoding / decoding system 4300 that can utilize the techniques disclosed herein. The video encoding / decoding system 4300 may include a source device 4310 and a target device 4320. The source device 4310 generates encoded video data, and this source device 4310 may be referred to as a video encoding device. The target device 4320 can decode the encoded video data generated by the source device 4310, and this target device 4320 may be referred to as a video decoding device.
[0206] Source device 4310 may include video source 4312, video encoder 4314, and input / output (I / O) interface 4316. Video source 4312 may include sources such as video capture devices, interfaces for receiving video data from video content providers, and / or computer graphics systems for generating video data, or combinations of these sources. Video data may include one or more pictures. Video encoder 4314 encodes the video data from video source 4312 to generate a bitstream. The bitstream may include a sequence of bits forming a coded representation of the video data. The bitstream may include coded pictures and associated data. A coded picture is a coded representation of a picture. Associated data may include sequence parameter sets, picture parameter sets, and other syntax structures. I / O interface 4316 may include a modulator / demodulator (modem) and / or a transmitter. Encoded video data may be transmitted directly to target device 4320 via network 4330 through I / O interface 4316. Encoded video data may also be stored on storage medium / server 4340 for access by target device 4320.
[0207] Target device 4320 may include I / O interface 4326, video decoder 4324, and display device 4322. I / O interface 4326 may include a receiver and / or a modem. I / O interface 4326 may acquire encoded video data from source device 4310 or storage medium / server 4340. Video decoder 4324 may decode the encoded video data. Display device 4322 may display the decoded video data to a user. Display device 4322 may be integrated with target device 4320 or may be external to target device 4320, wherein target device 4320 may be configured to interface with an external display device.
[0208] The video encoder 4314 and the video decoder 4324 can operate according to video compression standards, such as the High Efficiency Video Codec (HEVC) standard, the Multi-Functional Video Codec (VVM) standard, and other existing and / or further standards.
[0209] Figure 5 This is a block diagram illustrating an example of a video encoder 4400, which can be... Figure 4 The system 4300 shown includes a video encoder 4314. The video encoder 4400 can be configured to perform any or all of the techniques disclosed herein. The video encoder 4400 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of the video encoder 4400. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.
[0210] The functional components of the video encoder 4400 may include a segmentation unit 4401, a prediction unit 4402 (which may include a mode selection unit 4403, a motion estimation unit 4404, a motion compensation unit 4405, and an intra-frame prediction unit 4406), a residual generation unit 4407, a transform processing unit 4408, a quantization unit 4409, an inverse quantization unit 4410, an inverse transform unit 4411, a reconstruction unit 4412, a buffer 4413, and an entropy coding unit 4414.
[0211] In other examples, the video encoder 4400 may include more, fewer, or different functional components. In one example, the prediction unit 4402 may include an intra-block copy (IBC) unit. The IBC unit can perform prediction in an IBC mode, where at least one reference picture is the picture in which the current video block is located.
[0212] Furthermore, some components such as the motion estimation unit 4404 and the motion compensation unit 4405 can be highly integrated, but for illustrative purposes, these components are represented separately in the example of the video encoder 4400.
[0213] The segmentation unit 4401 can segment an image into one or more video blocks. The video encoder 4400 and the video decoder 4500 can support various video block sizes.
[0214] The mode selection unit 4403 can select one of several encoding / decoding modes (intra-frame encoding / decoding or inter-frame encoding / decoding), for example, based on error results, and provide the resulting intra-frame or inter-frame encoded / decoded block to the residual generation unit 4407 to generate residual block data, and to the reconstruction unit 4412 to reconstruct the coded block for use as a reference image. In some examples, the mode selection unit 4403 can select an intra-frame / inter-frame joint prediction (CIIP) mode, where prediction is based on inter-frame prediction signals and intra-frame prediction signals. In the case of inter-frame prediction, the mode selection unit 4403 can also select a resolution for the block based on motion vectors (e.g., sub-pixel precision or integer pixel precision).
[0215] To perform inter-frame prediction on the current video block, motion estimation unit 4404 can generate motion information for the current video block by comparing one or more reference frames from buffer 4413 with the current video block. Motion compensation unit 4405 can determine the predicted video block for the current video block based on the motion information and decoded samples of images from buffer 4413 other than the image associated with the current video block.
[0216] The motion estimation unit 4404 and the motion compensation unit 4405 can perform different operations on the current video block, for example, depending on whether the current video block is in an I-band, P-band, or B-band.
[0217] In some examples, motion estimation unit 4404 can perform unidirectional prediction on the current video block, and can search for reference images in list 0 or list 1 to find a reference video block for the current video block. Motion estimation unit 4404 can then generate a reference index indicating the reference image containing the reference video block in list 0 or list 1, and a motion vector indicating the spatial displacement between the current video block and the reference video block. Motion estimation unit 4404 can output the reference index, prediction direction indicator, and motion vector as motion information for the current video block. Motion compensation unit 4405 can generate a predicted video block for the current block based on the reference video block indicated by the motion information of the current video block.
[0218] In other examples, motion estimation unit 4404 can perform bidirectional prediction on the current video block. Motion estimation unit 4404 can search for reference images in list 0 to find a reference video block for the current video block, and can also search for reference images in list 1 to find another reference video block for the current video block. Motion estimation unit 4404 can then generate reference indices indicating the reference images containing the reference video blocks in lists 0 and 1, and motion vectors indicating the spatial displacement between the reference video blocks and the current video block. Motion estimation unit 4404 can output the reference index and motion vector of the current video block as motion information for the current video block. Motion compensation unit 4405 can generate a predicted video block for the current video block based on the reference video blocks indicated by the motion information of the current video block.
[0219] In some examples, the motion estimation unit 4404 can output a complete set of motion information for use in the decoder's decoding process. In some examples, the motion estimation unit 4404 may not output a complete set of motion information for the current video. Instead, the motion estimation unit 4404 can reference the motion information of another video block to transmit the motion information of the current video block via a signal. For example, the motion estimation unit 4404 may determine that the motion information of the current video block is sufficiently similar to the motion information of neighboring video blocks.
[0220] In one example, the motion estimation unit 4404 may indicate a value to the video decoder 4500 in the syntax structure associated with the current video block, which indicates that the current video block has the same motion information as another video block.
[0221] In another example, motion estimation unit 4404 may identify another video block and motion vector difference (MVD) in the syntax structure associated with the current video block. The motion vector difference indicates the difference between the motion vector of the current video block and the motion vector of the indicated video block. Video decoder 4500 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.
[0222] As discussed above, the video encoder 4400 can transmit motion vectors via signaling in a predictive manner. Two examples of predictive signaling techniques that can be implemented by the video encoder 4400 include Advanced Motion Vector Prediction (AMVP) and Merge Pattern Signaling.
[0223] Intra-prediction unit 4406 can perform intra-prediction on the current video block. When intra-prediction unit 4406 performs intra-prediction on the current video block, it can generate prediction data for the current video block based on decoded samples of other video blocks in the same frame. The prediction data for the current video block can include the predicted video block and various syntax elements.
[0224] The residual generation unit 4407 can generate residual data for the current video block by subtracting (or more) predicted video blocks from the current video block. The residual data for the current video block may include residual video blocks corresponding to different sample components of the samples in the current video block.
[0225] In other examples, such as in skip mode, there may be no residual data for the current video block, and the residual generation unit 4407 may not perform subtraction operations.
[0226] The transform processing unit 4408 can generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to the residual video blocks associated with the current video block.
[0227] After the transform processing unit 4408 generates a transform coefficient video block associated with the current video block, the quantization unit 4409 can quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values associated with the current video block.
[0228] The inverse quantization unit 4410 and the inverse transform unit 4411 can apply inverse quantization and inverse transform to the transform coefficient video block respectively to reconstruct the residual video block from the transform coefficient video block. The reconstruction unit 4412 can add the reconstructed residual video block to the corresponding samples of one or more predicted video blocks generated by the prediction unit 4402 to generate a reconstructed video block associated with the current block, which is stored in the buffer 4413.
[0229] After the video block is reconstructed by reconstruction unit 4412, a loop filtering operation can be performed to reduce video block artifacts in the video block.
[0230] The entropy encoding unit 4414 can receive data from other functional components of the video encoder 4400. When the entropy encoding unit 4414 receives data, it can perform one or more entropy encoding operations to generate entropy-encoded data and output a bitstream including the entropy-encoded data.
[0231] Figure 6 This is a block diagram illustrating an example of a video decoder 4500, which can be... Figure 4 The system 4300 shown includes a video decoder 4324. The video decoder 4500 can be configured to perform any or all of the techniques disclosed herein. In the example shown, the video decoder 4500 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of the video decoder 4500. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.
[0232] In the example shown, the video decoder 4500 includes an entropy decoding unit 4501, a motion compensation unit 4502, an intra-frame prediction unit 4503, an inverse quantization unit 4504, an inverse transform unit 4505, a reconstruction unit 4506, and a buffer 4507. In some examples, the video decoder 4500 can perform a decoding process that is generally contrasted with the encoding process described with respect to the video encoder 4400.
[0233] The entropy decoding unit 4501 can retrieve the encoded bitstream. The encoded bitstream may include entropy-encoded video data (e.g., encoded video data blocks). The entropy decoding unit 4501 can decode the entropy-encoded video data, and based on the entropy-decoded video data, the motion compensation unit 4502 can determine motion information including motion vectors, motion vector precision, reference image list index, and other motion information. The motion compensation unit 4502 can determine this information, for example, by executing AMVP and Merge modes.
[0234] The motion compensation unit 4502 can generate motion compensation blocks and can perform interpolation based on an interpolation filter. The identifier of the interpolation filter to be used, with sub-pixel accuracy, can be included in the syntax element.
[0235] The motion compensation unit 4502 can use interpolation filters, such as those used by the video encoder 4400 during the encoding of a video block, to calculate interpolations for sub-integer pixels of a reference block. The motion compensation unit 4502 can determine the interpolation filter used by the video encoder 4400 based on the received syntax information, and the motion compensation unit 4502 can use the interpolation filter to generate a prediction block.
[0236] The motion compensation unit 4502 may use some syntax information to determine the size of the blocks used to encode (multiple) frames and / or (multiple) stripes of the encoded video sequence, segmentation information describing how each macroblock of the image of the encoded video sequence is segmented, a mode indicating how each segment is encoded, one or more reference frames (and a list of reference frames) for each inter-frame codec block, and other information for decoding the encoded video sequence.
[0237] Intra-prediction unit 4503 can use, for example, an intra-prediction mode received in the bitstream to form prediction blocks from spatially adjacent blocks. Inverse quantization unit 4504 performs inverse quantization (i.e., dequantization) on the quantized video block coefficients provided in the bitstream and decoded by entropy decoding unit 4501. Inverse transform unit 4505 applies the inverse transform.
[0238] The reconstruction unit 4506 can add the residual block to the corresponding predicted block generated by the motion compensation unit 4502 or the intra-frame prediction unit 4503 to form a decoded block. If necessary, a deblocking filter can also be used to filter the decoded block to remove block artifacts. The decoded video block is then stored in a buffer 4507, which provides a reference block for subsequent motion compensation / intra-frame prediction and also generates decoded video for presentation on a display device.
[0239] Figure 7 This is a schematic diagram of an example encoder 4600. Encoder 4600 is suitable for implementing VVC techniques. Encoder 4600 includes three loop filters: a deblocking filter (DF) 4602, a sample adaptive compensation (SAO) 4604, and an adaptive loop filter (ALF) 4606. Unlike DF 4602, which uses predefined filters, SAO 4604 and ALF 4606 utilize the original samples of the current image to reduce the mean square error between the original and reconstructed samples, respectively, by adding compensation and by applying a finite impulse response (FIR) filter, where the side information of the encoding and decoding is transmitted through signal transmission offsets and filter coefficients. ALF 4606 is located in the last processing stage of each image and can be thought of as a tool attempting to capture and repair artifacts caused by previous stages.
[0240] The encoder 4600 also includes an intra-frame prediction component 4608 and a motion estimation / compensation (ME / MC) component 4610 configured to receive input video. The intra-frame prediction component 4608 is configured to perform intra-frame prediction, while the ME / MC component 4610 is configured to perform inter-frame prediction using reference images obtained from a reference image buffer 4612. Residual blocks from inter-frame or intra-frame prediction are fed into a transform (T) component 4614 and a quantization (Q) component 4616 to generate quantized residual transform coefficients, which are then fed into an entropy coding component 4618. The entropy coding component 4618 entropy-encodes the prediction results and the quantized transform coefficients and transmits them to a video decoder (not shown). The quantization component output from the quantization component 4616 can be fed into an inverse quantization (IQ) component 4620, an inverse transform component 4622, and a reconstruction (REC) component 4624. REC component 4624 is able to output images to DF 4602, SAO 4604 and ALF 4606 for filtering before these images are stored in reference image buffer 4612.
[0241] The following provides a list of preferred solutions as examples.
[0242] The following solutions illustrate examples of the techniques discussed in this article.
[0243] 1. A method for processing media data, comprising: determining a Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header containing one or more bytes of data, wherein the SEI RBSP header is included in the SEI RBSP and preceding one or more SEI messages carried in the SEI RBSP; and performing a conversion between visual media data and a bitstream based on the SEI RBSP header.
[0244] 2. The method according to Solution 1, wherein the SEI RBSP header includes information applicable to all SEI messages carried in the SEI RBSP and information applicable to all SEI messages carried in the SEI Network Abstraction Layer (NAL) unit.
[0245] 3. The method according to solution 1 or 2, wherein the SEI RBSP header includes information applicable to at least one SEI message carried in the SEI NAL unit.
[0246] 4. The method according to any one of solutions 1-3, wherein the SEI RBSP header includes an indication of whether all SEI messages carried in the SEINAL unit are considered essential or necessary to the application by the encoder or the content provider.
[0247] 5. The method according to any one of solutions 1-4, wherein the SEI RBSP header includes an indication of whether all SEI messages carried in the SEINAL unit can be considered essential or necessary to the application by the encoder or the content provider.
[0248] 6. The method according to any one of solutions 1-5, wherein the SEI RBSP header includes an indication of whether at least one SEI message carried in the SEINAL unit is considered by the encoder or the content provider to be essential or necessary for the application.
[0249] 7. The method according to any one of solutions 1-6, wherein the SEI RBSP header includes an indication as to whether at least one SEI message carried in the SEINAL unit can be considered essential or necessary to the application by the encoder or the content provider.
[0250] 8. The method according to any one of solutions 1-7, wherein the indication is a 1-bit flag having a first value and a second value, wherein the first value (e.g., 1) indicates that the SEI message contained in the SEI RBSP is considered necessary, and the second value (e.g., 0) indicates that the SEI message contained in the SEI RBSP is not considered necessary.
[0251] 9. The method according to any one of solutions 1-8, wherein the indication is a 2-bit syntax element having a first value, a second value, and a third value, wherein the first value indicates that the SEI message contained in the SEI RBSP is considered necessary, the second value indicates that the SEI message contained in the SEI RBSP is considered unnecessary, and the third value indicates that the necessity of the SEI message contained in the SEIRBSP has not been determined.
[0252] 10. The method according to any one of solutions 1-9, wherein the SEI RBSP header includes an indication of whether the SEINAL unit is a prefix SEI NAL unit or a suffix SEI NAL unit.
[0253] 11. The method according to any one of solutions 1-10, wherein: the prefix SEI NAL unit must be the same as the SEI NAL unit in VVC or HEVC whose nal_unit_type is equal to PREFIX_SEI_NUT, preceding the first VCL NAL unit among all VCL NAL units associated with the SEI NAL unit; or the suffix SEI NAL unit must be the same as the SEI NAL unit in VVC or HEVC whose nal_unit_type is equal to SUFFIX_SEI_NUT, following the last VCL NAL unit among all VCL NAL units associated with the SEI NAL unit.
[0254] 12. The method according to any one of solutions 1-11, wherein the SEI RBSP header includes a type length indicator that indicates the length (in bits) of the SEI payload type syntax element (e.g., named payload_type) of each SEI message contained in the SEI NAL unit.
[0255] 13. The method according to any one of solutions 1-12, wherein the type length indicator is a 1-bit flag, or the 1-bit flag equal to 0 indicates that the length is 8 bits, and the 1-bit flag equal to 0 indicates that the length is 16 bits, or the 1-bit flag equal to 0 indicates that the length is 8 bits, and the 1-bit flag equal to 0 indicates that the length is 10 bits.
[0256] 14. The method according to any one of solutions 1-13, wherein the type length indicator is a 2-bit syntax element, or the 2-bit syntax element is not allowed to be equal to 0 (therefore at least one bit is always equal to 1), or the type length indicator is an N-bit syntax element, where N is an integer greater than 2.
[0257] 15. The method according to any one of solutions 1-14, wherein the SEI RBSP header includes a size length indicator that indicates the length (in bits) of the SEI payload size syntax element (e.g., named payload_size) of each SEI message contained in the SEI NAL unit.
[0258] 16. The method according to any one of solutions 1-15, wherein the type length indicator is a 2-bit syntax element, or the 2-bit syntax element equal to 0, 1, 2, and 3 indicates the length of 8, 16, 24, and 32 bits respectively, or the 2-bit syntax element equal to 0, 1, 2, and 3 indicates the length of 4, 8, 16, and 24 bits respectively, or the 2-bit syntax element is not allowed to be equal to 0 (therefore at least one bit is always equal to 1), or the 2-bit syntax element equal to 1, 2, and 3 indicates the length of 8, 16, and 24 bits respectively, or the 2-bit syntax element equal to 1, 2, and 3 indicates the length of 8, 16, and 32 bits respectively.
[0259] 17. The method according to any one of solutions 1-16, wherein the type length indicator is an N-bit syntax element, where N is an integer greater than 2, or the N-bit syntax element is not allowed to be equal to 0 (therefore at least one bit is always equal to 1), or the SEI RBSP header includes one or more reserved bits, or all of the one or more reserved bits are equal to 0, or all of the one or more reserved bits are equal to 1, or one of the one or more reserved bits is equal to 1 and the remaining reserved bits of the one or more reserved bits are equal to 0, or the reserved bits are before the type length indicator and the size length indicator, or the reserved bits are after the type length indicator and the size length indicator, or wherein the SEI RBSP header always includes at least one bit equal to 1.
[0260] 18. The method according to any one of solutions 1-17, wherein in the SEI message header (which contains one or more bytes of data preceding the SEI payload in the SEI message), a syntax element (e.g., named payload_type) indicating the SEI payload type is u(v) encoded / decoded, and the length of the syntax element (in bits) is indicated by the type length indicator in the SEI RBSP header.
[0261] 19. The method according to any one of solutions 1-18, wherein in the SEI message header, a syntax element (e.g., named payload_size) indicating the SEI payload size is u(v) encoded and decoded, and the length of the syntax element (in bits) is indicated by the size length indicator in the SEI RBSP header.
[0262] 20. The method according to any one of solutions 1-19, wherein the type length indication is included in the SEI message header instead of the SEI RBSP header, and the syntax element (e.g., named payload_size) indicating the SEI payload type in the SEI message header is u(v) encoded and decoded, and the length of the syntax element (in bits) is indicated by the type length indication in the SEI message header.
[0263] 21. The method according to any one of solutions 1-20, wherein the size length indication is included in the SEI message header instead of the SEI RBSP header, and a syntax element (e.g., named payload_size) indicating the SEI payload size in the SEI message header is u(v) encoded and decoded, and the length of the syntax element (in bits) is indicated by the type length indication in the SEI message header.
[0264] 22. The method according to any one of solutions 1-21, wherein no type length indication is included in the SEI message header, and no type length indication is included in the SEI RBSP header, and the SEI message header indicates that the syntax element of the SEI payload type (e.g., named payload_type) is encoded / decoded by ue(v).
[0265] 23. The method according to any one of solutions 1-22, wherein no size length indication is included in the SEI message header, and no size length indication is included in the SEI RBSP header, and the syntax element in the SEI message header indicating the SEI payload size (e.g., named payload_size) is encoded / decoded by ue(v).
[0266] 24. The method according to any one of solutions 1-23, wherein in the SEI message header, after a syntax element indicating the SEI payload type (e.g., named payload_type) and a syntax element indicating the SEI payload size (e.g., named payload_size), there is a byte alignment check, followed by byte alignment bits equal to 0, until it is byte aligned.
[0267] 25. The method according to any one of solutions 1-24, wherein for VVC, a new NAL unit type (e.g., nal_unit_type with a value of 26, e.g., named NEW_SEI_NUT) is specified for SEINAL units containing SEI RBSPs, wherein the SEI RBSP has an SEI RBSP header and / or an SEI message header as specified in one of the methods described above.
[0268] 26. The method according to any one of solutions 1-25, wherein for VVC, two new NAL unit types (e.g., nal_unit_type values of 26 and 27, e.g., named PREFIX_NEW_SEI_NUT and SUFFIX_NEW_SEI_NUT) are specified for SEI NAL units containing SEI RBSPs, wherein the SEI RBSPs have the SEI RBSP syntax and SEI message syntax currently specified in VVC.
[0269] 27. The method according to any one of solutions 1-26, wherein the SEI NAL unit with nal_unit_type equal to PREFIX_NEW_SEI_NUT is a prefixed SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to PREFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0270] 28. The method according to any one of solutions 1-27, wherein the SEI NAL unit with nal_unit_type equal to SUFFIX_NEW_SEI_NUT is specified to be a suffix SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to SUFFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0271] 29. The method according to any one of solutions 1-28, wherein for HEVC, a new NAL unit type (e.g., nal_unit_type with a value of 41, e.g., named NEW_SEI_NUT) is specified for SEI NAL units containing SEI RBSPs, wherein the SEI RBSP has an SEI RBSP header and / or an SEI message header as specified in one of the methods described above.
[0272] 30. The method according to any one of solutions 1-29, wherein for HEVC, two new NAL unit types (e.g., nal_unit_type values 41 and 42, e.g., named PREFIX_NEW_SEI_NUT and SUFFIX_NEW_SEI_NUT) are specified for SEI NAL units containing SEI RBSPs, wherein the SEI RBSPs have the SEI RBSP syntax and SEI message syntax currently specified in HEVC.
[0273] 31. The method according to any one of solutions 1-30, wherein the SEI NAL unit with nal_unit_type equal to PREFIX_NEW_SEI_NUT must be a prefix SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to PREFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0274] 32. The method according to any one of solutions 1-31, wherein the SEI NAL unit with nal_unit_type equal to SUFFIX_NEW_SEI_NUT is a suffix SEI NAL unit (the same as the SEI NAL unit with nal_unit_type equal to SUFFIX_SEI_NUT), and the SEI message in the SEI NAL unit is considered by, for example, an encoder or content provider to be essential (or necessary) to the application.
[0275] 33. The method according to any one of solutions 1-32, wherein for AVC, a new NAL unit type (e.g., nal_unit_type with a value of 17, e.g., named NEW_SEI_NUT) is specified for SEINAL units containing SEI RBSPs, wherein the SEI RBSP has an SEI RBSP header and / or an SEI message header as specified in one of the methods described above.
[0276] 34. The method according to any one of solutions 1-33, wherein for new video codec standards other than VVC, HEVC and AVC, a specific NAL unit type value of nal_unit_type (e.g., named SEI_NUT) is specified for SEI NAL units containing SEI RBSPs, wherein the SEI RBSPs have SEIRBSP headers and / or SEI message headers as specified in one of the methods described above, and no other NAL unit types are specified for SEI NAL units.
[0277] 35. The method according to any one of solutions 1-34, wherein one indication is included in the Real-time Transport Protocol (RTP) packet payload structure to indicate that the SEI message contained in one or more specific SEI NAL units contained in the RTP packet is considered by, for example, by the sender or content provider to be essential (or necessary) for the application.
[0278] 36. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method according to any one of solutions 1-35.
[0279] 37. A non-transitory computer-readable medium comprising a computer program product for use by a video codec apparatus, the computer program product including computer-executable instructions stored on the non-transitory computer-readable medium such that when the computer-executable instructions are executed by a processor, the video codec apparatus performs the method according to any one of solutions 1-35.
[0280] 38. A non-transitory computer-readable recording medium storing a bitstream of video generated by a method performed by a video processing apparatus, wherein the method comprises: determining a Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header containing one or more bytes of data, wherein the SEI RBSP header is included in the SEI RBSP and precedes one or more SEI messages carried in the SEI RBSP; and generating a bitstream based on the determination.
[0281] 39. A method for storing a bitstream of video, comprising: determining a Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header containing one or more bytes of data, wherein the SEI RBSP header is included in a SEIRBSP and preceding one or more SEI messages carried in the SEI RBSP; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.
[0282] 40. A method, apparatus, or system described in this document.
[0283] In the described solution, the encoder conforms to the format rules by generating an encoded representation based on those rules. In the described solution, the decoder parses the syntax elements in the encoded representation using known information about their presence or absence, based on the format rules, to generate the decoded video.
[0284] In this document, the term "video processing" can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm can be applied during the conversion from the pixel representation of a video to the corresponding bitstream representation, and vice versa. For example, the bitstream representation of the current video block can correspond to bits at the same position in the bitstream defined by the syntax or bits propagated at different positions. For example, a macroblock can be encoded based on the error residual value after transformation and encoding / decoding, and can also use bits from the header and other fields in the bitstream. Furthermore, during the conversion, the decoder can, based on this determination, parse the bitstream knowing whether some fields may or may not be present, as described in the solutions above. Similarly, the encoder can determine whether to include or exclude specific syntax fields and generate the codec representation accordingly by including or excluding syntax fields from the codec representation.
[0285] The disclosed and other solutions, examples, embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in a combination of one or more. The disclosed embodiments and other embodiments can be implemented as one or more computer program products, i.e., one or more computer program instruction modules encoded on a computer-readable medium for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a storage device, a material composition affecting machine-readable propagation signals, or a combination thereof. The term "data processing apparatus" includes all means, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus may also include code that creates an execution environment for an associated computer program, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination thereof. Propagation signals are artificially generated signals, such as machine-generated electrical signals, optical signals, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device.
[0286] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language, including compiled or interpreted languages, and can be deployed in any form, including standalone programs or modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the related program, or in multiple co-located files (e.g., a file storing one or more modules, subroutines, or code portions). A computer program can be deployed to execute on one computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communications network.
[0287] The processing and logic flows described in this document can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating outputs. The processing and logic flows can also be executed by special-purpose logic circuitry, and the devices can be implemented as special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits).
[0288] Processors suitable for executing computer programs include, for example, general-purpose and special-purpose microprocessors, and any one or more processors in any type of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor that executes instructions and one or more storage devices that store the instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks. However, a computer does not necessarily have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable hard disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. The processor and memory may be supplemented by or incorporated into special-purpose logic circuitry.
[0289] While this patent document contains numerous details, these details should not be construed as limiting any subject matter or the scope of the claims, but rather as descriptions of features specific to particular embodiments of a particular technology. In this patent document, certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments, or in any suitable sub-combination. Furthermore, although features may function in certain combinations as described above, and even were originally claimed in this manner, in some cases one or more features in the claimed combination may be removed from that combination, and the claimed combination may be for sub-combinations or variations thereof.
[0290] Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed sequentially in the specific order or sequence shown, or requiring all shown operations to be performed in order to achieve the desired result. Furthermore, the division of various system components in the embodiments described in this patent document should not be construed as requiring such division in all embodiments.
[0291] Only a few implementations and examples are described, and other implementations, improvements and variations can be made based on what is described and shown in this patent document.
[0292] When there is no intermediate component (other than a line, trace, or other medium between the first and second components), the first component is directly coupled to the second component. When there is an intermediate component other than a line, trace, or other medium between the first and second components, the first component is indirectly coupled to the second component. The term "coupled" and its variations include direct coupling and indirect coupling. The use of the term "about" means including a range of ±10% of the following figures, unless otherwise specified.
[0293] While several embodiments have been provided in this disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of this disclosure. The present examples are intended to be illustrative rather than limiting and are not intended to be limited to the details given herein. For example, various elements or components may be combined or integrated into another system, or certain features may be omitted or not implemented.
[0294] Furthermore, the technologies, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments can be combined or integrated with other systems, modules, technologies, or methods without departing from the scope of this disclosure. Other items shown or discussed as couplings can be directly connected or indirectly coupled or communicated through some interface, device, or intermediate component (whether electrically, mechanically, or otherwise). Other examples of variations, substitutions, and alterations will be apparent to those skilled in the art and can be made without departing from the spirit and scope of this disclosure.
Claims
1. A method for processing media data, comprising: One or more bytes of data are determined from the Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header, wherein the SEI RBSP header is included in the SEI RBSP and precedes one or more SEI messages carried in the SEI RBSP; and The conversion between visual media data and bitstream is performed based on the SEI RBSP header.
2. The method as described in claim 1, wherein, The SEI RBSP header includes information applicable to all SEI messages carried in the SEI RBSP and information applicable to all SEI messages carried in the SEI Network Abstraction Layer (NAL) unit.
3. The method as described in claim 1 or 2, wherein, The SEI RBSP header includes information applicable to at least one SEI message carried in the SEI NAL unit.
4. The method according to any one of claims 1-3, wherein, The SEI RBSP header includes a first indication indicating whether all SEI messages carried in the SEI NAL unit are considered essential or necessary to the application by the encoder or content provider.
5. The method according to any one of claims 1-4, wherein, The SEI RBSP header includes a first indication that indicates whether all SEI messages carried in the SEI NAL unit can be considered essential or necessary to the application by the encoder or content provider.
6. The method according to any one of claims 1-5, wherein, The SEI RBSP header includes a first indication indicating whether at least one SEI message carried in the SEI NAL unit is considered essential or necessary to the application by the encoder or content provider.
7. The method according to any one of claims 1-6, wherein, The SEI RBSP header includes a first indication that indicates whether at least one SEI message carried in the SEI NAL unit can be considered essential or necessary to the application by the encoder or content provider.
8. The method according to any one of claims 1-7, wherein, The first indication is a 1-bit flag with a first value and a second value, wherein the first value indicates that the SEI message contained in the SEI RBSP is considered necessary, and the second value indicates that the SEI message contained in the SEI RBSP is not considered necessary.
9. The method according to any one of claims 1-8, wherein, The first indication is a 2-bit syntax element having a first value, a second value, and a third value, wherein the first value indicates that the SEI message contained in the SEI RBSP is considered necessary, the second value indicates that the SEI message contained in the SEI RBSP is considered unnecessary, and the third value indicates that the necessity of the SEI message contained in the SEI RBSP has not been determined.
10. The method according to any one of claims 1-9, wherein, The SEI RBSP header includes a second indication that indicates whether the SEI NAL unit is a prefix SEI NAL unit or a suffix SEI NAL unit.
11. The method according to any one of claims 1-10, wherein, The prefix SEI NAL unit must precede the first VCL NAL unit among all the Video Codec Layer (VCL) Network Abstraction Layer (NAL) units associated with the SEI NAL unit, or the suffix SEI NAL unit must follow the last VCL NAL unit among all the VCL NAL units associated with the SEI NAL unit.
12. The method according to any one of claims 1-11, wherein, The SEI RBSP header includes a type length indicator that indicates the bit length of the SEI payload type syntax element (payload_type) of each SEI message contained in the SEI NAL unit.
13. The method according to any one of claims 1-12, wherein, The type length indicator is a 1-bit flag, or the 1-bit flag equal to 0 indicates that the length is 8 bits, and the 1-bit flag equal to 0 indicates that the length is 16 bits, or the 1-bit flag equal to 0 indicates that the length is 8 bits, and the 1-bit flag equal to 0 indicates that the length is 10 bits.
14. The method according to any one of claims 1-13, wherein, The type length indicator is a 2-bit syntax element, or the 2-bit syntax element is not allowed to be equal to 0, so at least one of the two bits is always equal to 1, or the type length indicator is an N-bit syntax element, where N is an integer greater than 2.
15. The method according to any one of claims 1-14, wherein, The SEI RBSP header includes a size length indicator that indicates the length in bits of the SEI payload size syntax element (payload_size) of each SEI message contained in the SEI NAL unit.
16. The method according to any one of claims 1-15, wherein, The type length indicator is a 2-bit syntax element, or the 2-bit syntax element equal to 0, 1, 2, or 3 indicates a length of 8, 16, 24, and 32 bits, respectively; or the 2-bit syntax element equal to 0, 1, 2, or 3 indicates a length of 4, 8, 16, and 24 bits, respectively; or the 2-bit syntax element is not allowed to be equal to 0, such that at least one of the two bits is always equal to 1; or the 2-bit syntax element equal to 1, 2, or 3 indicates a length of 8, 16, and 24 bits, respectively; or the 2-bit syntax element equal to 1, 2, or 3 indicates a length of 8, 16, and 32 bits, respectively.
17. The method according to any one of claims 1-16, wherein, The type length indicator is an N-bit syntax element, where N is an integer greater than 2, or the N-bit syntax element is not allowed to be equal to 0, such that at least one of the three bits is always equal to 1, or the SEI RBSP header includes one or more reserved bits, or all of the one or more reserved bits are equal to 0, or all of the one or more reserved bits are equal to 1, or one of the one or more reserved bits is equal to 1 and the remaining reserved bits of the one or more reserved bits are equal to 0, or the reserved bits are before the type length indicator and the size length indicator, or the reserved bits are after the type length indicator and the size length indicator, or the SEI RBSP header always includes at least one bit equal to 1.
18. The method according to any one of claims 1-17, wherein, The SEI message header includes one or more bytes of data preceding the SEI payload in the SEI message, a syntax element indicating the SEI payload type (payload_type) that is variable unsigned (u(v)) encoding / decoding, and the bit length of the syntax element is indicated by the type length indicator in the SEI RBSP header.
19. The method according to any one of claims 1-18, wherein, The SEI message header contains a syntax element that indicates the SEI payload size (payload_size), the syntax element being u(v) encoded and decoded, and the bit length of the syntax element being indicated by the size length indicator in the SEI RBSP header.
20. The method according to any one of claims 1-19, wherein, The type length indication is included in the SEI message header, and the SEI message header contains a syntax element indicating the SEI payload type (payload_size), the syntax element is u(v) encoded and decoded, and the length of the syntax element in bits is indicated by the type length indication in the SEI message header.
21. The method according to any one of claims 1-20, wherein, The size length indication is included in the SEI message header, and the SEI message header contains a syntax element indicating the SEI payload size, the syntax element being u(v) encoded and decoded, and the bit length of the syntax element being indicated by the type length indication in the SEI message header.
22. The method according to any one of claims 1-21, wherein, No type length indication is included in the SEI message header, and no type length indication is included in the SEI RBSP header, which includes a syntax element indicating the SEI payload type (payload_type), and the syntax element is encoded and decoded by a variable unsigned integer Exp-Golomb(ue(v)).
23. The method according to any one of claims 1-22, wherein, No size length indication is included in the SEI message header, and no size length indication is included in the SEI RBSP header, which includes a syntax element indicating the SEI payload size (payload_size), and the syntax element is encoded and decoded by ue(v).
24. The method according to any one of claims 1-23, wherein, The SEI header includes a byte alignment check, which is followed by a byte alignment bit equal to 0 until the SEI header bytes are aligned. The byte alignment check and the byte alignment bit are located after the syntax elements indicating the SEI payload type (payload_type) and the syntax elements indicating the SEI payload size (payload_size).
25. The method according to any one of claims 1-24, wherein, A NAL unit type (nal_unit_type) with a value of 26 named New SEI NAL Unit Type (NEW_SEI_NUT) is specified for use in Multifunction Video Codec (VVC), and NEW_SEI_NUT is specified for use in SEI NAL units that contain SEI RBSPs with the SEI RBSP header or the SEI message header.
26. The method according to any one of claims 1-25, wherein, A nal_unit_type with a value of 26 named Prefix SEI NAL Unit Type (PREFIX_NEW_SEI_NUT) is specified for VVC, and a nal_unit_type with a value of 27 named Suffix SEI NAL Unit Type (SUFFIX_NEW_SEI_NUT) is specified for VVC. PREFIX_NEW_SEI_NUT and SUFFIX_NEW_SEI_NUT are specified for SEINAL units containing SEI RBSPs with SEI RBSP syntax and SEI message syntax.
27. The method according to any one of claims 1-26, wherein, SEI NAL units whose nal_unit_type is equal to PREFIX_NEW_SEI_NUT must be prefixed SEI NAL units, and the SEI messages in the SEI NAL units must be considered essential or necessary to the application by the encoder or content provider.
28. The method according to any one of claims 1-27, wherein, SEI NAL units whose nal_unit_type is equal to SUFFIX_NEW_SEI_NUT must be suffix SEI NAL units, and the SEI messages in the SEI NAL units must be considered essential or necessary to the application by the encoder or content provider.
29. The method according to any one of claims 1-28, wherein, The nal_unit_type with a value of 41, named New SEI NAL Unit Type (NEW_SEI_NUT), is specified for use in High Efficiency Video Coding (HEVC), and NEW_SEI_NUT is specified for use in SEI NAL units that contain SEI RBSPs with the SEI RBSP header or the SEI message header.
30. The method according to any one of claims 1-29, wherein, A nal_unit_type with a value of 41 named Prefix SEI NAL Unit Type (PREFIX_NEW_SEI_NUT) is specified for HEVC, and a nal_unit_type with a value of 42 named Suffix SEI NAL Unit Type (SUFFIX_NEW_SEI_NUT) is specified for HEVC. PREFIX_NEW_SEI_NUT and SUFFIX_NEW_SEI_NUT are specified for SEI NAL units that contain SEI RBSPs with SEI RBSP syntax and SEI message syntax.
31. The method according to any one of claims 1-30, wherein, SEI NAL units whose nal_unit_type is equal to PREFIX_NEW_SEI_NUT must be prefixed SEI NAL units, and the SEI messages in the SEI NAL units must be considered essential or necessary to the application by the encoder or content provider.
32. The method according to any one of claims 1-31, wherein, SEI NAL units whose nal_unit_type is equal to SUFFIX_NEW_SEI_NUT must be suffix SEI NAL units, and the SEI messages in the SEI NAL units must be considered essential or necessary to the application by the encoder or content provider.
33. The method according to any one of claims 1-32, wherein, The nal_unit_type with a value of 17, named New SEI NAL Unit Type (NEW_SEI_NUT), is specified for use in Advanced Video Codec (AVC), and NEW_SEI_NUT is specified for use in SEI NAL units that contain SEI RBSPs with the SEI RBSP header or the SEI message header.
34. The method according to any one of claims 1-33, wherein, A nal_unit_type with a specific value named SEI NAL Unit Type (SEI_NUT) is specified for use in video codec standards. SEI_NUT is specified for use in SEI NAL units that contain SEI RBSPs with the SEI RBSP header or the SEI message header as specified. No other NAL unit types are specified for use in SEI NAL units.
35. The method according to any one of claims 1-34, wherein, An indication is included in the Real-Time Transport Protocol (RTP) packet payload structure to indicate that the sender or content provider considers the SEI message contained in one or more SEI NAL units within the RTP packet to be essential or necessary for the application.
36. The method according to any one of claims 1-35, wherein, The conversion includes encoding the visual media data into the bitstream.
37. The method according to any one of claims 1-35, wherein, The conversion includes decoding the visual media data from the bitstream.
38. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein, When executed by the processor, the instructions cause the processor to perform the method as described in any one of claims 1-37.
39. A non-transitory computer-readable medium comprising a computer program product for use with a video encoding / decoding device, wherein, The computer program product includes computer-executable instructions stored on the non-transitory computer-readable medium, such that when the computer-executable instructions are executed by a processor, the video codec device performs the method as described in any one of claims 1-37.
40. A non-transitory computer-readable recording medium storing a bitstream of video generated by a method performed by a video processing apparatus, wherein, The method includes: One or more bytes of data are determined from the Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header, wherein the SEI RBSP header is included in the SEI RBSP and precedes one or more SEI messages carried in the SEI RBSP; and Based on the determination, a bit stream is generated.
41. A method for storing a video bitstream, comprising: One or more bytes of data are determined from the Supplemental Enhancement Information (SEI) Raw Byte Sequence Payload (RBSP) header, wherein the SEI RBSP header is included in the SEI RBSP and precedes one or more SEI messages carried in the SEI RBSP; Based on the determination, a bit stream is generated; and The bit stream is stored in a non-transitory computer-readable recording medium.