Output of the previous picture for the picture that starts a new coded video sequence in video coding.

Abstract

To provide a method of decoding a coded video bitstream.SOLUTION: A method of decoding a coded video bitstream is provided. A method includes: receiving a coded video bitstream, where the coded video bitstream contains a gradual decoding refreshment (GDR) picture and a first flag having a first value; setting a second value of a second flag equal to the first value of the first flag; emptying any previously-decoded pictures from a decoded picture buffer (DPB) based on the second flag having the second value; and decoding a current picture after the DPB has been emptied. A corresponding encoding method is also provided.SELECTED DRAWING: Figure 8

Description

Technical Field

[0001] Generally, the present disclosure describes techniques for supporting the output of previously decoded pictures in video coding. More specifically, the present disclosure enables outputting a previously decoded picture corresponding to a random access point picture that starts a coded video sequence (CVS) from a decoded picture buffer (DPB).

Background Art

[0002] The amount of video data required to depict even relatively short videos is substantial, which can be difficult when the data is streamed or communicated over a communication network with a limited bandwidth capacity in other ways. Therefore, video data is generally compressed before being communicated over modern telecommunications networks. Also, since memory resources may be limited, the size of the video can also be a problem when the video is stored in a storage device. Video compression devices often use software and / or hardware at the source to code the video data before transmission or storage, thereby reducing the amount of data required to represent digital video images. The compressed data is then received at the destination by a video decompression device that decodes the video data. Improved compression and decompression techniques that improve the compression ratio without sacrificing much in image quality are desirable because network resources are limited and the demand for higher video quality is constantly increasing.

Summary of the Invention

[0003] The first aspect relates to a decoding method implemented by a video decoder. The method includes receiving a coded video bitstream, the coded video bitstream comprising a stepwise decoded refresh (GDR) picture and a first flag having a first value; setting a second value of a second flag equal to the first value of the first flag; clearing any previously decoded pictures from a decoded picture buffer (DPB) based on the second flag having a second value after the GDR picture has been decoded; and decoding the current picture after the DPB has been cleared.

[0004] This method provides a technique for outputting the previous picture (e.g., a previously decoded picture) in the decoded picture buffer (DPB) when random access point pictures other than instantaneous decoder refresh (IDR) pictures (e.g., clean random access (CRA) pictures, stepped random access (GRA) pictures, or stepped decode refresh (GDR) pictures, CVSS pictures, etc.) are encountered in the decoding order. By emptying the DPB with previously decoded pictures when a random access point picture is reached, the DPB is prevented from overflowing, and more continuous playback is facilitated. Thus, the coder / decoder (also known as "codec") in video coding is improved compared to current codecs. In practical terms, the improved video coding process provides a better user experience when video is sent, received, and / or viewed.

[0005] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment provides that the GDR picture is not the first picture in the coded video bitstream.

[0006] Optionally, in any of the embodiments described above, another implementation of the embodiment provides that the GDR picture is placed in a video coding layer (VCL) network abstraction layer (NAL) unit having a stepped decode refresh (GDR) network abstraction layer (NAL) unit type (GDR_NUT).

[0007] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment provides that the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag.

[0008] Optionally, in any of the embodiments described above, another implementation of the embodiment provides setting the DPB fullness parameter to zero when the first flag is set to a first value.

[0009] Optionally, in any of the embodiments described above, another implementation of the embodiment provides that the DPB is empty after the GDR picture has been decoded.

[0010] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment provides displaying an image generated based on the current picture.

[0011] A second aspect relates to an encoding method implemented by a video encoder. This method includes: the video encoder determining random access points of a video sequence; the video encoder encoding a stepwise decoded refresh (GDR) picture to the video sequence at the random access points; the video encoder setting a flag to a first value that instructs the video decoder to empty any previously decoded pictures from the decoded picture buffer (DPB); the video encoder generating a video bitstream containing the video sequence with the GDR picture at the random access points and the flag; and the video encoder storing the video bitstream for transmission toward the video decoder.

[0012] This method provides a technique for outputting the previous picture (e.g., a previously decoded picture) in the decoded picture buffer (DPB) when random access point pictures other than instantaneous decoder refresh (IDR) pictures (e.g., clean random access (CRA) pictures, stepped random access (GRA) pictures, or stepped decode refresh (GDR) pictures, CVSS pictures, etc.) are encountered in the decoding order. By emptying the DPB with previously decoded pictures when a random access point picture is reached, the DPB is prevented from overflowing, and more continuous playback is facilitated. Thus, the coder / decoder (also known as "codec") in video coding is improved compared to current codecs. In practical terms, the improved video coding process provides a better user experience when video is sent, received, and / or viewed.

[0013] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment is instructed that the GDR picture is not the first picture in the video bitstream, and that the video decoder is instructed to empty the DPB after the GDR picture has been decoded.

[0014] Optionally, in any of the embodiments described above, another implementation of the embodiment provides that the GDR picture is placed in a video coding layer (VCL) network abstraction layer (NAL) unit having a stepped decode refresh (GDR) network abstraction layer (NAL) unit type (GDR_NUT).

[0015] Optionally, in any of the embodiments described above, another implementation of the embodiment provides instructing the video decoder to set the DPB fullness parameter to zero when the flag is set to the first value.

[0016] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment provides that the flag is specified as no_output_of_prior_pics_flag.

[0017] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment is such that the first value of the flag is 1.

[0018] A third aspect relates to a decoding device. The decoding device includes a receiver configured to receive a coded video bitstream, and a memory coupled to the receiver, the memory including a memory for storing instructions, and a processor coupled to the memory, the processor being configured to execute an instruction causing the decoding device to receive a coded video bitstream, the coded video bitstream including a Stepwise Decode Refresh (GDR) picture and a first flag having a first value, to set a second value of a second flag equal to the first value of the first flag, to empty any previously decoded picture from a Decoded Picture Buffer (DPB) based on the second flag having a second value, and to decode the current picture after the DPB is empty.

[0019] This decoding device provides a technique for outputting the previous picture (e.g., a previously decoded picture) in the decoded picture buffer (DPB) when random access point pictures other than instantaneous decoder refresh (IDR) pictures (e.g., clean random access (CRA) pictures, stepped random access (GRA) pictures, or stepped decoded refresh (GDR) pictures, CVSS pictures, etc.) are encountered in the decoding order. By emptying the DPB with previously decoded pictures when a random access point picture is reached, the DPB is prevented from overflowing, and more continuous playback is facilitated. Thus, the coder / decoder (also known as "codec") in video coding is improved compared to current codecs. In practical terms, the improved video coding process provides a better user experience when video is sent, received, and / or viewed.

[0020] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment provides that the GDR picture is not the first picture in the coded video bitstream.

[0021] Optionally, in any of the aforementioned embodiments, another implementation of the embodiment provides that the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag.

[0022] Optionally, in any of the embodiments described above, another implementation of the embodiment provides a display configured to display a picture generated based on the current picture.

[0023] A fourth aspect relates to an encoding device. The encoding device includes a memory containing instructions; a processor coupled to the memory, the processor configured to implement instructions to the encoding device to: determine random access points of a video sequence; encode a stepwise decoded refresh (GDR) picture into the video sequence at the random access points; set a flag to a first value that instructs a video decoder to empty any previously decoded pictures from a decoded picture buffer (DPB); and generate a video bitstream containing a video sequence having the GDR picture at the random access points and the flag; and a transmitter coupled to the processor, the transmitter configured to transmit a video bitstream to a video decoder.

[0024] This encoding device provides a technique for outputting the previous picture (e.g., a previously decoded picture) in the decoded picture buffer (DPB) when random access point pictures other than instantaneous decoder refresh (IDR) pictures (e.g., clean random access (CRA) pictures, stepped random access (GRA) pictures, or stepped decode refresh (GDR) pictures, CVSS pictures, etc.) are encountered in the decoding order. By emptying the DPB with previously decoded pictures when a random access point picture is reached, the DPB is prevented from overflowing, and more continuous playback is facilitated. Thus, the coder / decoder (also known as "codec") in video coding is improved compared to current codecs. In practical terms, the improved video coding process provides a better user experience when video is sent, received, and / or viewed.

[0025] Optionally, in any of the foregoing aspects, another implementation of the aspect provides that the GDR picture is not the first picture of the coded video bitstream.

[0026] Optionally, in any of the foregoing aspects, another implementation of the aspect provides that the flag is specified as the no_output_of_prior_pics_flag.

[0027] Optionally, in any of the foregoing aspects, another implementation of the aspect provides that the memory stores the bitstream before the transmitter transmits the bitstream towards the video decoder.

[0028] A fifth aspect relates to a coding apparatus. The coding apparatus includes a receiver configured to receive a picture to be coded or a bitstream to be decoded, a transmitter coupled to the receiver, the transmitter being configured to transmit the bitstream to a decoder or transmit the decoded image to a display, a memory coupled to at least one of the receiver or the transmitter, the memory being configured to store instructions, and a processor coupled to the memory, the processor being configured to execute the instructions stored in the memory for performing any of the methods disclosed herein.

[0029] This coding device provides a technique for output of a previous picture (e.g., a previously decoded picture) in a decoded picture buffer (DPB) when a random access point picture other than an instantaneous decoder refresh (IDR) picture (e.g., a clean random access (CRA) picture, a gradual random access (GRA) picture, or a gradual decoding refresh (GDR) picture, a CVSS picture, etc.) is encountered in decoding order. When reaching a random access point picture, emptying the previously decoded pictures from the DPB prevents the DPB from overflowing and promotes more continuous playback. Thus, a coder / decoder (also known as a “codec”) in video coding is improved as compared with a current codec. As a practical matter, the improved video coding process provides a better user experience to a user when the video is sent, received, and / or viewed.

[0030] Optionally, in any of the foregoing aspects, another implementation of the aspect provides a display configured to display a picture.

[0031] A sixth aspect relates to a system. The system includes an encoder and a decoder in communication with the encoder, and the encoder or the decoder includes a decoding device, an encoding device, or a coding device disclosed herein.

[0032] This system provides a technique for outputting the previous picture (e.g., a previously decoded picture) in the decoded picture buffer (DPB) when random access point pictures other than instantaneous decoder refresh (IDR) pictures (e.g., clean random access (CRA) pictures, stepped random access (GRA) pictures, or stepped decode refresh (GDR) pictures, CVSS pictures, etc.) are encountered in the decoding order. By emptying the DPB with previously decoded pictures when a random access point picture is reached, the DPB is prevented from overflowing, and more continuous playback is facilitated. Thus, the coder / decoder (also known as "codec") in video coding is improved compared to current codecs. In practical terms, the improved video coding process provides a better user experience when video is sent, received, and / or viewed.

[0033] A seventh aspect relates to coding means, which includes: receiving means configured to receive a picture to encode or a bitstream to decode; transmitting means coupled to the receiving means, the transmitting means configured to transmit a bitstream to a decoding means or a decoded image to a display means; storage means coupled to at least one of the receiving means or the transmitting means, the storage means configured to store instructions; and processing means coupled to the storage means, the processing means configured to execute instructions stored in the storage means for performing any of the methods disclosed herein.

[0034] This coding technique provides a method for outputting the previous picture (e.g., a previously decoded picture) in the decoded picture buffer (DPB) when random access point pictures other than instantaneous decoder refresh (IDR) pictures (e.g., clean random access (CRA) pictures, stepped random access (GRA) pictures, or stepped decode refresh (GDR) pictures, CVSS pictures, etc.) are encountered in the decoding order. By emptying the DPB with previously decoded pictures when a random access point picture is reached, the DPB is prevented from overflowing, and more continuous playback is facilitated. Thus, the coder / decoder (also known as "codec") in video coding is improved compared to current codecs. In practical terms, the improved video coding process provides a better user experience when video is sent, received, and / or viewed.

[0035] For clarity, any one of the embodiments described above may be combined with one or more of the other embodiments described above to create new embodiments within the scope of this disclosure.

[0036] These and other features will be more clearly understood from the following detailed description, which is obtained in conjunction with the attached drawings and claims. [Brief explanation of the drawing]

[0037] To gain a more complete understanding of this disclosure, refer to the following brief description obtained in connection with the attached drawings and detailed description, where similar reference numbers represent similar parts.

[0038] [Figure 1] This is a block diagram illustrating an exemplary coding system that can utilize GDR technology.

[0039] [Figure 2] This is a block diagram illustrating an example video encoder that can implement GDR technology.

[0040] [Figure 3] This is a block diagram showing an example of a video decoder that can implement GDR technology.

[0041] [Figure 4] This represents the relationship between the IRAP picture and the subsequent picture relative to the leading picture, expressed in terms of the decoding order and presentation order.

[0042] [Figure 5] This demonstrates a stepwise decoding and refreshing technique.

[0043] [Figure 6] This is a schematic diagram illustrating undesirable motion exploration.

[0044] [Figure 7] This shows a video bitstream configured to implement Clean Random Access (CRA) technology.

[0045] [Figure 8] This is an embodiment of a method for decoding a coded video bitstream.

[0046] [Figure 9] This is an embodiment of a method for encoding a coded video bitstream.

[0047] [Figure 10] This is a schematic diagram of a video coding device.

[0048] [Figure 11] This is a schematic diagram of an embodiment of the coding means 1100. [Modes for carrying out the invention]

[0049] Firstly, exemplary implementations of one or more embodiments are provided below, but it should be understood that the disclosed systems and / or methods can be carried out using any number of techniques, whether currently known or existing. This disclosure is not limited in any way to the exemplary implementations, drawings, and techniques shown below, including the exemplary designs and implementations shown and described herein, but may be modified within the scope of the appended claims, along with the entire scope of their equivalents.

[0050] Figure 1 is a block diagram illustrating an exemplary coding system 10 that may utilize the video coding techniques described herein. As shown in Figure 1, the coding system 10 includes a source device 12 that provides coded video data to be later decoded by a destination device 14. In particular, the source device 12 may provide the video data to the destination device 14 via a computer-readable medium 16. The source device 12 and destination device 14 may include any of the wide range of devices, including desktop computers, notebook (e.g., laptop) computers, tablet computers, set-top boxes, telephone handsets such as so-called "smartphones," so-called "smart" pads, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, and the like. In some cases, the source device 12 and destination device 14 may be equipped for wireless communication.

[0051] The destination device 14 may receive encoded video data that is decoded via a computer-readable medium 16. The computer-readable medium 16 may include any type of medium or device capable of transferring the encoded video data from the source device 12 to the destination device 14. For example, the computer-readable medium 16 may include a communication medium that enables the source device 12 to directly transmit the encoded video data to the destination device 14 in real time. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the destination device 14. The communication medium may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include routers, switches, base stations, or other equipment useful for facilitating communication from the source device 12 to the destination device 14.

[0052] In some examples, the encoded data may be output to a storage device from the output interface 22. Similarly, the encoded data may be accessed from the storage device through the input interface. The storage device may include any of a variety of distributed or locally accessed data storage media, such as a hard drive, Blu-ray disc, digital video disc (DVD), compact disc read-only memory (CD-ROM), flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing the encoded video data. In further examples, the storage device may correspond to a file server or another intermediate storage device capable of storing the encoded video generated by the source device 12. The destination device 14 may access the stored video data from the storage device via streaming or download. The file server may be any type of server capable of storing the encoded video data and sending the encoded video data to the destination device 14. Exemplary file servers include, for example, a web server (for a website), a File Transfer Protocol (FTP) server, a network-attached storage (NAS) device, or a local disk drive. The destination device 14 may access the encoded video data via any standard data connection, including an Internet connection. This may include a wireless channel (e.g., Wi-Fi connection), a wired connection (e.g., digital subscriber line (DSL), cable modem, etc.), or a combination of both preferred for accessing encoded video data stored on a file server. Transmission of the encoded video data from the storage device may be streaming transmission, download transmission, or a combination thereof.

[0053] The technology of this disclosure is not necessarily limited to wireless applications or settings. The technology may be applied to video coding supporting any of a variety of multimedia applications, such as wireless television broadcasting, cable television transmission, satellite television transmission, internet streaming video transmission such as Dynamic Adaptive Streaming (DASH) over HTTP, encoded digital video on a data storage medium, decoding of digital video stored on a data storage medium, or other applications. In some examples, the coding system 10 may be configured to support one-way or two-way video transmission to support applications such as video streaming, video playback, video broadcasting, and / or video phone calls.

[0054] In the example shown in Figure 1, the source device 12 includes a video source 18, a video encoder 20, and an output interface 22. The destination device 14 includes an input interface 28, a video decoder 30, and a display device 32. According to this disclosure, the video encoder 20 of the source device 12 and / or the video decoder 30 of the destination device 14 may be configured to apply techniques for video coding. In other examples, the source device and destination device may include other components or arrangements. For example, the source device 12 may receive video data from an external video source such as an external camera. Similarly, the destination device 14 may interface with an external display device rather than including an integrated display device.

[0055] The coding system 10 shown in Figure 1 is merely an example. The technique for video coding may be performed by any digital video coding and / or decoding device. While the technique of this disclosure is generally performed by a video coding device, the technique may also be performed by a video encoder / decoder, typically referred to as a “CODEC”. Furthermore, the technique of this disclosure may also be performed by a video preprocessor. The video encoder and / or decoder may be a graphics processing unit (GPU) or a similar device.

[0056] Source device 12 and destination device 14 are merely examples of coding devices that generate encoded video data for source device 12 to transmit to destination device 14. In some examples, source device 12 and destination device 14 may operate in a substantially symmetrical manner such that each of source device 12 and destination device 14 includes video encoding and decoding components. Thus, coding system 10 can support one-way or two-way video transmission between video devices 12, 14 for, for example, video streaming, video playback, video broadcasting, or video phone.

[0057] The video source 18 of source device 12 may include a video capture device such as a video camera, a video archive containing previously captured video, and / or a video supply interface for receiving video from a video content provider. As a further alternative, the video source 18 may generate computer graphics-based data as source video, or as a combination of live video, archived video, and computer-generated video.

[0058] In some cases, when the video source 18 is a video camera, the source device 12 and the destination device 14 may form a so-called camera phone or video phone. However, as stated above, the techniques described herein may be applicable to video coding in general and to wireless and / or wired applications. In each case, captured, pre-captured, or computer-generated video may be encoded by the video encoder 20. The encoded video information may then be output to a computer-readable medium 16 via the output interface 22.

[0059] The computer-readable medium 16 may include temporary media such as wireless broadcast or wired network transmission, or storage media such as hard disks, flash drives, compact discs, digital video discs, Blu-ray discs, or other computer-readable media. In some examples, a network server (not shown) may receive encoded video data from source device 12 and provide the encoded video data to destination device 14, for example, via network transmission. Similarly, a computing device in media manufacturing equipment, such as a disc stamping machine, may receive encoded video data from source device 12 and produce a disc containing the encoded video data. Thus, the computer-readable medium 16 may be understood to include one or more computer-readable media in various forms in various examples.

[0060] The input interface 28 of the destination device 14 receives information from the computer-readable medium 16. The information on the computer-readable medium 16 may include syntactic information defined by the video encoder 20, which is also used by the video decoder 30, and includes syntactic elements that describe the features and / or processing of blocks and / or other coded units, such as groups of pictures (GOPs). The display device 32 displays the decoded video data to the user and may include any of various display devices such as a cathode ray tube (CRT), liquid crystal display (LCD), plasma display, organic light-emitting diode (OLED) display, or other types of display devices.

[0061] The video encoder 20 and video decoder 30 may operate in accordance with a video coding standard, such as the High Efficiency Video Coding (HEVC) standard currently under development, and may conform to the HEVC Test Model (HM). Alternatively, the video encoder 20 and video decoder 30 may operate in accordance with other proprietary or industrial standards, such as the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) H.264 standard, also known as the Video Expert Group (MPEG)-4 Part 10, Advanced Video Coding (AVC), H265 / HEVC, or extensions of such standards. However, the technology of this disclosure is not limited to any particular coding standard. Other examples of video coding standards include MPEG-2 and ITU-T H.263. Although not shown in Figure 1, in some embodiments, the video encoder 20 and video decoder 30 may be integrated with an audio encoder and decoder, respectively, and may include a suitable multiplexer-demultiplexer unit or other hardware and software to handle the encoding of both audio and video in a common data stream or separate data streams. Where applicable, the MUX-DEMUX unit may conform to the ITU H.223 Multiplexer Protocol or other protocols such as the User Datagram Protocol (UDP).

[0062] The video encoder 20 and the video decoder 30 may each be implemented as one or more suitable encoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the technology is partially implemented in software, the device may store instructions for the software in a suitable non-temporary computer-readable medium and execute the instructions in hardware using one or more processors to perform the technology of this disclosure. Each of the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, any of which may be integrated as part of a combined encoder / decoder (CODEC) within their respective devices. A device including the video encoder 20 and / or video decoder 30 may include an integrated circuit, a microprocessor, and / or a wireless communication device such as a cellular telephone.

[0063] Figure 2 is a block diagram showing an example of a video encoder 20 that may implement video coding techniques. The video encoder 20 may perform intra-coding and inter-coding of video blocks within a video slice. Intra-coding relies on spatial prediction to reduce or eliminate spatial redundancy in video within a given video frame or picture. Inter-coding relies on temporal prediction to reduce or eliminate temporal redundancy in video within adjacent frames or pictures of a video sequence. Intra-mode (I-mode) may refer to any of several space-based coding modes. Inter-modes, such as one-way (also known as single-prediction) prediction (P-mode) or two-way (two-way prediction) (B-mode), may refer to any of several time-based coding modes.

[0064] As shown in Figure 2, the video encoder 20 receives the current video block in the video frame to be encoded. In the example in Figure 2, the video encoder 20 includes a mode selection unit 40, a reference frame memory 64, a summer 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The mode selection unit 40 then includes a motion compensation unit 44, a motion estimation unit 42, an intra-prediction (also known as intra-prediction) unit 46, and a partition unit 48. In video block reconstruction, the video encoder 20 also includes an inverse quantization unit 58, an inverse transform unit 60, and a summer 62. Additionally, an unblocking filter (not shown in Figure 2) may be included to filter block boundaries in order to remove blocky artifacts from the reconstructed video. If desired, the unblocking filter typically filters the output of the summer 62. In addition to the unblocking filter, additional filters (in-loop or post-loop) may also be used. Such a filter is not shown for simplicity, but if desired, it may filter the output of totalizer 50 (as an in-loop filter).

[0065] During the encoding process, the video encoder 20 receives video frames or slices to be coded. The frames or slices may be divided into multiple video blocks. The motion estimation unit 42 and the motion compensation unit 44 perform inter-predictive coding of the received video blocks for one or more blocks within one or more reference frames to provide temporal predictions. Alternatively, the intra-predictive unit 46 may perform intra-predictive coding of the received video blocks for one or more adjacent blocks within the same frame or slice as the block being coded to provide spatial predictions. The video encoder 20 may perform multiple coding passes, for example, to select an appropriate coding mode for each block of video data.

[0066] Furthermore, the partition unit 48 may partition blocks of video data into sub-blocks based on an evaluation of a previous partitioning scheme in a previous coding pass. For example, the partition unit 48 may first partition a frame or slice into the largest coding unit (LCU), and then partition each LCU into sub-coding units based on rate distortion analysis (e.g., rate distortion optimization). Furthermore, the mode selection unit 40 may generate a quad-tree data structure indicating that the LCUs are to be partitioned into sub-CUs. The leaf nodes CU of the quad-tree may include one or more prediction units (PUs) and one or more transformation units (TUs).

[0067] This disclosure uses the term “block” to refer to any CU, PU, ​​or TU in the context of HEVC, or a similar data structure in the context of other standards (e.g., macroblocks and their subblocks in H.264 / AVC). A CU includes a coding node and PUs and TUs associated with the coding node. The size of a CU corresponds to the size of the coding node and is square. The size of a CU may range from 8x8 pixels to the size of a tree block of 64x64 pixels or more. Each CU may contain one or more PUs and one or more TUs. Syntactic data associated with a CU may, for example, describe the partitioning of the CU into one or more PUs. The partitioning mode may differ depending on whether the CU is skip or direct mode coding, intra predictive mode coding, or inter predictive (also known as inter predictive) mode coding. PUs may be partitioned in a non-square shape. Syntactic data associated with a CU may also describe, for example, the partitioning of the CU into one or more TUs according to a quad tree. The TU can be square or non-square (e.g., rectangular).

[0068] The mode selection unit 40 may, for example, select one of intra or intercoding modes based on the error result, provide the resulting intra or intercoding block to the totalizer 50, generate residual block data, provide it to the totalizer 62, and reconstruct the encoded block for use as a reference frame. The mode selection unit 40 also provides syntactic elements such as motion vectors, intra-mode indicators, partition information, and other such syntactic information to the entropy coding unit 56.

[0069] The motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, but are shown separately for conceptual purposes. The motion estimation performed by the motion estimation unit 42 is a process that generates motion vectors, which estimate the motion of a video block. The motion vectors may, for example, represent the displacement of the PU of a video block in the current video frame or picture relative to a predicted block (or other coded unit) in a reference frame relative to the current block (or other coded unit) coded in the current frame. A predicted block is a block that is found to closely match a coded block with respect to pixel differences, which can be determined by absolute difference (SAD), sum of squared differences (SSD), or sum of other difference metrics. In some examples, the video encoder 20 may calculate values ​​for sub-integer pixel positions of a reference picture stored in the reference frame memory 64. For example, the video encoder 20 may interpolate values ​​for quarter-pixel, eighth-pixel, or other fractional pixel positions of the reference image. Therefore, the motion estimation unit 42 may perform motion search for all pixel positions and fractional pixel positions and output motion vectors with fractional pixel accuracy.

[0070] The motion estimation unit 42 calculates the motion vector of the PU for a video block in an intercoded slice by comparing the PU's position with the predicted block's position in a reference picture. The reference picture may be selected from a first reference picture list (list 0) or a second reference picture list (list 1), each of which identifies one or more reference pictures stored in the reference frame memory 64. The motion estimation unit 42 transmits the calculated motion vector to the contropy coding unit 56 and the motion compensation unit 44.

[0071] Motion compensation performed by the motion compensation unit 44 may involve fetching or generating a predicted block based on the motion vector determined by the motion estimation unit 42. In some examples, the motion estimation unit 42 and the motion compensation unit 44 may also be functionally integrated. Upon receiving the motion vector for the current video block's PU, the motion compensation unit 44 can locate the position of the predicted block pointed to by the motion vector in one of the reference picture lists. The totalizer 50 forms a residual video block by subtracting the pixel values ​​of the predicted block from the encoded pixel values ​​of the current video block, as described later, which forms the pixel difference value. Generally, the motion estimation unit 42 performs motion estimation for the luma component, and the motion compensation unit 44 uses a motion vector calculated based on the luma component for both the chroma and luma components. The mode selection unit 40 may also generate syntactic elements related to video blocks and video slices for use by the video decoder 30 when decoding video blocks of video slices.

[0072] The intra-prediction unit 46 may intra-predict the current block as an alternative to the intra-prediction performed by the motion estimation unit 42 and the motion compensation unit 44, as described above. In particular, the intra-prediction unit 46 may determine the intra-prediction mode to use to encode the current block. In some examples, the intra-prediction unit 46 may encode the current block using various intra-prediction modes, for example, in separate encoding paths, and the intra-prediction unit 46 (or, in some examples, the mode selection unit 40) may select an appropriate intra-prediction mode to use from the tested modes.

[0073] For example, the intra-prediction unit 46 may calculate rate distortion values ​​using rate distortion analysis for various tested intra-prediction modes and select the intra-prediction mode with the best rate distortion characteristics among the tested modes. Rate distortion analysis generally determines the amount of distortion (or error) between the encoded block and the original unencoded block encoded to produce the encoded block, and the bit rate (i.e., the number of bits) used to produce the encoded block. The intra-prediction unit 46 may calculate a ratio from the distortion and rate for various encoded blocks to determine which intra-prediction mode exhibits the best rate distortion value for a block.

[0074] Additionally, the intra-prediction unit 46 may be configured to code depth blocks of the depth map using a depth modeling mode (DMM). The mode selection unit 40 may determine, for example, using rate-distortion optimization (RDO), whether an available DMM mode yields better coding results than the intra-prediction mode and other DMM modes. The texture image data corresponding to the depth map may be stored in the reference frame memory 64. The motion estimation unit 42 and the motion compensation unit 44 may also be configured to inter-predict depth blocks of the depth map.

[0075] After selecting an intra-prediction mode for a block (for example, one of the conventional intra-prediction mode or DMM mode), the intra-prediction unit 46 may provide the entropy coding unit 56 with information indicating the selected intra-prediction mode for the block. The entropy coding unit 56 may encode the information indicating the selected intra-prediction mode. The video encoder 20 may also include transmitted bitstream configuration data that can include multiple intra-prediction mode index tables and multiple modified intra-prediction mode index tables (also called codeword mapping tables), definitions of coding contexts for various blocks, and the most likely intra-prediction mode, intra-prediction mode index table, and modified intra-prediction mode index table to be used for each context.

[0076] The video encoder 20 forms a residual video block by subtracting predicted data from the mode selection unit 40 from the coded original video block. The totalizer 50 represents one or more components that perform this subtraction operation.

[0077] The transformation processing unit 52 applies a transformation, such as a discrete cosine transform (DCT) or a conceptually similar transformation, to the residual block to generate a video block containing residual transformation coefficient values. The transformation processing unit 52 may also perform other transformations conceptually similar to the DCT. Wavelet transforms, integer transforms, subband transforms, or other types of transformations may also be used.

[0078] The conversion processing unit 52 applies the conversion to the residual block to generate a block of residual conversion coefficients. The conversion may convert the residual information from the pixel value domain to a conversion domain, such as the frequency domain. The conversion processing unit 52 may transmit the obtained conversion coefficients to the quantization unit 54. The quantization unit 54 quantizes the conversion coefficients to further reduce the bit rate. The quantization process may reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be modified by adjusting the quantization parameters. In some examples, the quantization unit 54 may then perform a scan of the matrix containing the quantized conversion coefficients. Alternatively, the entropy coding unit 56 may perform the scan.

[0079] After quantization, the entropy coding unit 56 entropy codes the quantized transformation coefficients. For example, the entropy coding unit 56 may perform context-adaptive variable-length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probabilistic interval partitioning entropy (PIPE) coding, or another entropy coding technique. In the case of context-based entropy coding, the context may be based on adjacent blocks. Following entropy coding by the entropy coding unit 56, the encoded bitstream may be transmitted to another device (e.g., a video decoder 30) or archived for later transmission or retrieval.

[0080] The inverse quantization unit 58 and the inverse transform unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel domain for later use, for example, as a reference block. The motion compensation unit 44 may calculate a reference block by adding the residual block to a prediction block of one of the frames in the reference frame memory 64. The motion compensation unit 44 may also apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values ​​for use in motion estimation. The totalizer 62 adds the reconstructed residual block to the motion-compensated prediction block generated by the motion compensation unit 44 to generate a reconstructed video block for storage in the reference frame memory 64. The reconstructed video block may be used by the motion estimation unit 42 and the motion compensation unit 44 as a reference block for intercoding the block in subsequent video frames.

[0081] Figure 3 is a block diagram showing an example of a video encoder 30 that can implement video coding technology. In the example of Figure 3, the video decoder 30 includes an entropy decoding unit 70, a motion compensation unit 72, an intra-prediction unit 74, an inverse quantization unit 76, an inverse transform unit 78, a reference frame memory 82, and a totalizer 80. In some examples, the video decoder 30 may perform a decoding path that is roughly the reverse of the coding path described with respect to the video encoder 20 (Figure 2). The motion compensation unit 72 may generate prediction data based on motion vectors received from the entropy decoding unit 70, while the intra-prediction unit 74 may generate prediction data based on an intra-prediction mode indicator received from the entropy decoding unit 70.

[0082] During the decoding process, the video decoder 30 receives an encoded video bitstream from the video encoder 20, representing the video blocks and associated syntactic elements of the encoded video slice. The entropy decoding unit 70 of the video decoder 30 decodes the bitstream and generates quantization coefficients, motion vectors or intra-predictive mode indicators, and other syntactic elements. The entropy decoding unit 70 transfers the motion vectors and other syntactic elements to the motion compensation unit 72. The video decoder 30 may also receive syntactic elements at the video slice level and / or video block level.

[0083] When a video slice is coded as an intra-coded (I) slice, the intra-prediction unit 74 may generate prediction data for the video blocks of the current video slice based on the signaled intra-prediction mode and data from previously decoded blocks of the current frame or picture. When a video frame is coded as an inter-coded (e.g., B, P, or GPB) slice, the motion compensation unit 72 generates prediction blocks for the video blocks of the current video slice based on motion vectors and other syntactic elements received from the entropy decoding unit 70. The prediction blocks may be generated from one of the reference pictures in one of the reference picture lists. The video decoder 30 may configure the reference frame lists, list 0 and list 1, using default configuration techniques based on reference pictures stored in the reference frame memory 82.

[0084] The motion compensation unit 72 determines the prediction information for the video blocks of the current video slice by analyzing the motion vectors and other syntactic elements, and uses the prediction information to generate the prediction blocks of the current video block to be decoded. For example, the motion compensation unit 72 uses some of the received syntactic elements to determine the prediction mode used to code the video blocks of the video slice (e.g., intra or interpredict), the interpredicted slice type (e.g., B slice, P slice, or GPB slice), one or more configuration pieces of reference picture list for the slice, the motion vector for each intercoded video block of the slice, the interpredicted status for each intercoded video block of the slice, and other information for decoding the video blocks in the current video slice.

[0085] The motion compensation unit 72 may also perform interpolation based on an interpolation filter. The motion compensation unit 72 may use the interpolation filter used by the video encoder 20 during video block encoding to calculate interpolation values ​​for sub-integer pixels of the reference block. In this case, the motion compensation unit 72 may determine the interpolation filter used by the video encoder 20 from the received syntactic elements and use the interpolation filter to generate the predicted block.

[0086] The texture image data corresponding to the depth map may be stored in the reference frame memory 82. The motion compensation unit 72 may also be configured to interpret depth blocks of the depth map.

[0087] In one embodiment, the video decoder 30 includes a user interface (UI) 84. The user interface 84 is configured to receive input from a user of the video decoder 30 (e.g., a network administrator). Through the user interface 84, the user can manage or change settings on the video decoder 30. For example, the user can input or otherwise provide values ​​for parameters (e.g., flags) to control the settings and / or operation of the video decoder 30 according to the user's preferences. The user interface 84 may be a graphical user interface (GUI) that allows the user to interact with the video decoder 30 via, for example, graphical icons, drop-down menus, check boxes, etc. In some cases, the user interface 84 may receive information from the user via a keyboard, mouse, or other peripheral device. In one embodiment, the user can access the user interface 84 via a smartphone, tablet device, personal computer located remotely from the video decoder 30, etc. As used herein, the user interface 84 may be referred to as an external input or external means.

[0088] With the above in mind, video compression techniques perform spatial (intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or eliminate redundancy inherent in video sequences. For block-based video coding, video slices (i.e., video pictures or portions of video pictures) may be partitioned into video blocks, which may be called tree blocks (CTBs), coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks in an intra-coded (I) slice of a picture are coded using spatial prediction with respect to reference samples in adjacent blocks within the same picture. Video blocks in an inter-coded (P or B) slice of a picture may use spatial prediction with respect to reference samples in adjacent blocks within the same picture, or temporal prediction with respect to reference samples in other reference pictures. Pictures may be called frames, and reference pictures may be called reference frames.

[0089] Spatial or temporal prediction yields a predicted block of the block to be coded. Residual data represents the pixel difference between the original block to be coded and the predicted block. Intercoded blocks are coded according to motion vectors pointing to the reference sample block forming the predicted block, and residual data shows the difference between the coded block and the predicted block. Intracoded blocks are coded according to the intracoded mode and residual data. For further compression, the residual data may be transformed from the pixel domain to the transformation domain, which yields residual transformation coefficients, which may then be quantized. The quantized transformation coefficients are initially placed in a two-dimensional array and scanned to generate a one-dimensional vector of transformation coefficients, and entropy coding may be applied to achieve further compression.

[0090] Image and video compression has experienced rapid growth, leading to various encoding standards. Such video encoding standards include Advanced Video Coding (AVC), also known as ITU-T H.261, International Organization for Standardization / International Electrotechnical Commission (ISO / IEC) MPEG-1 Part 2, ITU-T H.262 or ISO / IEC MPEG-2 Part 2, ITU-T H.263, ISO / IEC MPEG-4 Part 2, ITU-T H.264 or ISO / IEC MPEG-4 Part 10, and High Efficiency Video Coding (HEVC), also known as ITU-T H.265 or MPEG-H Part 2. AVC includes extensions such as Scalable Video Coding (SVC), Multiview Video Coding (MVC), Multiview Video Coding Plus Depth (MVC+D), and 3D AVC (3D-AVC). HEVC includes extensions such as Scalable HEVC (SHVC), Multiview HEVC (MV-HEVC), and 3D HEVC (3D-HEVC).

[0091] There is also a new video coding standard called Universal Video Coding (VVC), developed by the Joint Video Expert Team (JVET) of the ITU-T and ISO / IEC. The VVC standard has several working drafts, but in particular, one working draft of VVC, namely "Versatile Video Coding (Draft 5)" by B. Bross, J. Chen, and S. Liu, JVET-N1001-v3, 13th JVET Meeting, March 27, 2019 (VVC5 Draft5), is referred to herein.

[0092] The description of the technology disclosed herein is based on the general-purpose video coding of a video coding standard under development by the ITU-T and ISO / IEC joint video expert team. However, this technology is also applicable to other video codec specifications.

[0093] Figure 4 is a representation 400 of the relationship between an intra-random access (IRAP) picture 402 with respect to a leading picture 404 and a subsequent picture 406 in the decoding order 408 and presentation order 410. In one embodiment, the IRAP picture 402 is called an instantaneous decoder refresh (IDR) picture having a clean random access (CRA) picture or a random access decodeable (RADL) picture. In HEVC, IDR pictures, CRA pictures, and broken link access (BLA) pictures are all considered IRAP pictures 402. In VVC, at the 12th JVET meeting in October 2018, it was agreed that both IDR pictures and CRA pictures would be considered IRAP pictures. In one embodiment, broken link access (BLA) and stepwise decoder refresh (GDR) pictures may also be considered IRAP pictures. The decoding process of an encoded video sequence always starts with IRAP.

[0094] A CRA picture is an IRAP picture where each Video Coding Layer (VCL) Network Abstraction Layer (NAL) unit has a nal_unit_type equal to CRA_NUT. A CRA picture does not reference any other pictures for interpretation during its decoding process and may be the first picture in the bitstream in the decoding order, or it may appear later in the bitstream. A CRA picture may have an associated RADL or Random Access Skip First (RASL) picture. When a CRA picture has a NoOutputBeforeRecoveryFlag equal to 1, the associated RASL picture may not be decodeable because it may contain references to pictures that do not exist in the bitstream, and therefore is not output by the decoder.

[0095] As shown in Figure 4, leading pictures 404 (e.g., pictures 2 and 3) follow IRAP picture 402 in the decoding order 408, but precede IRAP picture 402 in the presentation order 410. Successor picture 406 follows IRAP picture 402 in both the decoding order 408 and the presentation order 410. Although two leading pictures 404 and one successor picture 406 are shown in Figure 4, those skilled in the art will understand that more or fewer leading pictures 404 and / or successor pictures 406 may be present in the decoding order 408 and presentation order 410 in actual applications.

[0096] The leading picture 404 in Figure 4 is divided into two types: Random Access Skip Lead (RASL) and RADL. When decoding begins with IRAP picture 402 (e.g., picture 1), the RADL picture (e.g., picture 3) can be properly decoded, but the RASL picture (e.g., picture 2) cannot. Therefore, the RASL picture is discarded. In light of the distinction between RADL and RASL pictures, the type of leading picture 404 associated with IRAP picture 402 should be identified as either RADL or RASL for efficient and proper coding. In HEVC, when RASL and RADL pictures are present, for RASL and RADL pictures associated with the same IRAP picture 402, the RASL picture is constrained to precede the RADL picture in presentation order 410.

[0097] IRAP picture 402 provides two important functions / benefits. First, the presence of IRAP picture 402 indicates that the decoding process can start from that picture. This function enables a random access feature in the bitstream, where the decoding process starts from that position in the bitstream, not necessarily the beginning of the bitstream, as long as IRAP picture 402 is present at that position. Second, the presence of IRAP picture 402 refreshes the decoding process so that coded pictures starting with IRAP picture 402, excluding RASL pictures, are coded without referencing the previous picture. As a result, the presence of IRAP picture 402 in the bitstream will prevent any errors that may occur during the decoding of pictures coded before IRAP picture 402 from propagating to IRAP picture 402 and the pictures that follow IRAP picture 402 in decoding order 408.

[0098] IRAP picture 402 provides important functionality, but comes with a penalty to compression efficiency. The presence of IRAP picture 402 causes a surge in bitrate. This penalty to compression efficiency is due to two reasons. Firstly, because IRAP picture 402 is an intra-predicted picture, the picture itself requires relatively more bits to represent compared to other pictures that are inter-predicted pictures (e.g., leading picture 404, following picture 406). Secondly, because the presence of IRAP picture 402 disrupts temporal prediction (this is because the decoder refreshes the decoding process, and one of the actions of the decoding process is to remove previous reference pictures in the decoded picture buffer (DPB)), IRAP picture 402 makes the coding of pictures following IRAP picture 402 in decoding order 408 less efficient (i.e., requires more bits to represent). This is because there are fewer reference pictures for those inter-predicted codings.

[0099] Among the picture types considered IRAP picture 402, IDR pictures in HEVC have different signaling and derivations compared to other picture types. Some of the differences are as follows:

[0100] In the signaling and derivation of the Picture Order Count (POC) value for an IDR picture, the most significant bit (MSB) of the POC is not derived from the previous significant picture, but is simply set to 0.

[0101] In terms of signaling information required for reference picture management, the slice header of an IDR picture does not contain any information that needs to be signaled to assist in reference picture management. Other picture types (i.e., CRA, trailing, temporal sublayer access, etc.) require information such as the reference picture set or other similar information (e.g., a reference picture list) described below for the reference picture marking process (i.e., the process of determining the state of reference pictures in the decoded picture buffer (DPB), whether they are used for reference or not). However, in IDR pictures, such information does not need to be signaled because the presence of the IDR indicates that the decoding process will simply mark all reference pictures in the DPB as not being used for reference.

[0102] In HEVC and VVC, IRAP picture 402 and leading picture 404 may each be contained within a single Network Abstraction Layer (NAL) unit. A set of NAL units is sometimes called an access unit. IRAP picture 402 and leading picture 404 are given different NAL unit types so that they can be easily identified by system-level applications. For example, a video splicer needs to understand the coded picture type without having to understand the excessive detail of syntactic elements in the coded bitstream, and in particular needs to identify IRAP picture 402 from non-IRAP pictures, and identify leading picture 404 from succeeding picture 406, including determining whether it is a RASL or RADL picture. Successing picture 406 is a picture related to IRAP picture 402 and which is after IRAP picture 402 in presentation order 410. A picture can follow a specific IRAP picture 402 in decoding order 408 and precede other IRAP pictures 402 in decoding order 408. To achieve this, assigning each IRAP picture 402 and leading picture 404 its own NAL unit type helps in such applications.

[0103] In HEVC, the NAL unit types for IRAP pictures include the following: BLA with Leading Picture (BLA_W_LP): A NAL unit of a corrupted link access (BLA) picture, which may be followed by one or more leading pictures in the decryption order. BLA with RADL (BLA_W_RADL): A NAL unit of a BLA picture where one or more RADL pictures may follow in the decoding order, but no RASL pictures follow. BLA without a leading picture (BLA_N_LP): A NAL unit of a BLA picture where the leading picture does not follow in the decoding order. IDR with RADL (IDR_W_RADL): A NAL unit of an IDR picture where one or more RADL pictures may follow in the decoding order, but no RASL pictures follow. IDR without a leading picture (IDR_N_LP): A NAL unit of an IDR picture where the leading picture does not follow in the decoding order. CRA: A Clean Random Access (CRA) picture NAL unit, which may be followed by a leading picture (RASL picture, RADL picture, or both). RADL: NAL unit of RADL picture. RASL: NAL unit of RASL picture.

[0104] In VVC, the NAL unit types for IRAP picture 402 and lead picture 404 are as follows: IDR with RADL (IDR_W_RADL): A NAL unit of an IDR picture where one or more RADL pictures may follow in the decoding order, but no RASL pictures follow. IDR without a leading picture (IDR_N_LP): A NAL unit of an IDR picture where the leading picture does not follow in the decoding order. CRA: A Clean Random Access (CRA) picture NAL unit, which may be followed by a leading picture (RASL picture, RADL picture, or both). RADL: NAL unit of RADL picture. RASL: NAL unit of RASL picture.

[0105] Figure 5 shows a video bitstream 550 configured to implement a stepwise decoded refresh (GDR) technique 500. As used herein, the video bitstream 550 may also be referred to as a coded video bitstream, a bitstream, or a variation thereof. As shown in Figure 5, the bitstream 550 includes a sequence parameter set (SPS) 552, a picture parameter set (PPS) 554, a slice header 556, and image data 558.

[0106] SPS552 contains data common to all pictures in a set of pictures (SOP). In contrast, PPS554 contains data common to all pictures. The slice header 556 contains information about the current slice, such as the slice type and which reference picture is used. SPS552 and PPS554 are sometimes commonly referred to as parameter sets. SPS552, PPS554, and slice header 556 are types of Network Abstraction Layer (NAL) units. A NAL unit is a syntactic structure that contains instructions for the type of data it follows (e.g., coded video data). NAL units are classified into Video Coding Layer (VCL) and non-VCL NAL units. A VCL NAL unit contains data representing the values ​​of samples in a video picture, while a non-VCL NAL unit contains any relevant additional information, such as parameter sets (essential header data applicable to many VCL NAL units) and supplemental enhancement information (timing information and other supplemental data that is not required to decode the values ​​of samples in a video picture but may enhance the usefulness of the decoded video signal). Those skilled in the art will understand that bitstream 550 may also contain other parameters and information in the actual application.

[0107] The image data 558 in Figure 5 includes data related to the image or video being encoded or decoded. The image data 558 may simply be referred to as the payload or data carried in the bitstream 550. In one embodiment, the image data 558 includes a CVS 508 (or CLVS) which includes a GDR picture 502, one or more subsequent pictures 504, and a recovery point picture 506. In one embodiment, the GDR picture 502 is referred to as the CVS start (CVSS) picture. The CVS 508 is a coded video sequence for each coded layer video sequence (CLVS) in the video bitstream 550. Notably, when the video bitstream 550 contains a single layer, the CVS and CLVS are the same. The CVS and CLVS differ only when the video bitstream 550 contains multiple layers. In one embodiment, the subsequent picture 504 may be considered a form of GDR picture because it precedes the recovery point picture 506 of the GDR period.

[0108] In one embodiment, the GDR picture 502, the subsequent picture 504, and the recovery point picture 506 may define the GDR period in the CVS 508. In one embodiment, the decoding sequence begins with the GDR picture 502, continues with the subsequent picture 504, and then proceeds to the recovery picture 506.

[0109] CVS508 is a series of pictures (or a portion thereof) beginning with GDR picture 502 and including all pictures (or a portion thereof) up to the next GDR picture (but not including it), or up to the end of the bitstream. The GDR period is a series of pictures beginning with GDR picture 502 and including recovery point picture 506, including all pictures up to that point. The decoding process for CVS508 always begins with GDR picture 502.

[0110] As shown in Figure 5, the GDR technique 500 or principle works on a series of pictures starting with GDR picture 502 and ending with recovery point picture 506. GDR picture 502 includes a refresh / clean region 510 containing blocks that have all been coded using intra-prediction (i.e., intra-predicted blocks) and an unrefreshed / dirty region 512 containing blocks that have all been coded using inter-prediction (i.e., inter-predicted blocks).

[0111] A subsequent picture 504 immediately adjacent to the GDR picture 502 includes a refresh / clean region 510 having a first portion 510A coded using intra-prediction and a second portion 510B coded using inter-prediction. The second portion 510B is coded, for example, by referencing the refresh / clean region 510 of the leading picture within the GDR period of CVS 508. As illustrated, the refresh / clean region 510 of the subsequent picture 504 expands as the coding process moves or progresses in a consistent direction (e.g., left to right), contracting the unrefreshed / dirty region 512 accordingly. Finally, a recovery point picture 506 containing only the refresh / clean region 510 is obtained from the coding process. In particular, as will be discussed further below, the second portion 510B of the refresh / clean region 510 coded as an inter-prediction block may refer only to the refresh / clean region 510 of the reference picture.

[0112] As shown in Figure 5, the GDR picture 502, the successor picture 504, and the recovery point picture 506 in CVS 508 are each contained within their own VCL NAL unit 530. A set of NAL units is sometimes referred to as an access unit.

[0113] In one embodiment, the VCL NAL unit 530 containing the GDR picture 502 in CVS 508 has a GDR NAL unit type (GDR_NUT). That is, in the embodiment, the VCL NAL unit 530 containing the GDR picture 502 in CVS 508 has its own unique NAL unit type for the subsequent picture 504 and the recovery point picture 506. In one embodiment, GDR_NUT allows the bitstream 550 to start with the GDR picture 502 rather than having to start with the IRAP picture. Specifying the VCL NAL unit 530 of the GDR picture 502 as GDR_NUT may indicate to the decoder, for example, that the initial VCL NAL unit 530 in CVS 508 contains the GDR picture 502. In one embodiment, the GDR picture 502 is the initial picture in CVS 508. In one embodiment, GDR picture 502 is the initial picture during the GDR period.

[0114] Figure 6 is a schematic diagram showing an undesirable motion search 600 when using encoder limits to support GDR. As shown, the motion search 600 shows the current picture 602 and the reference picture 604. The current picture 602 and the reference picture 604 each contain a refreshed region 606 coded with intra-prediction, a refreshed region 608 coded with inter-prediction, and an unrefreshed region 608, respectively. The refreshed regions 604, 606, and 608 are similar to the first portion 510A of the refresh / clean region 510, the second portion 510B of the refresh / clean region 510, and the unrefreshed / dirty region 512 in Figure 5.

[0115] During the motion search process, the encoder is constrained or prevented from selecting any motion vector 610 that yields a portion of the samples from reference block 612 located outside the refresh region 606. This occurs even when reference block 612 provides the best rate distortion cost criterion when predicting the current block 614 within the current picture 602. Thus, Figure 6 illustrates why using encoder constraints to support GDR is suboptimal in motion search 600.

[0116] Figure 7 shows a video bitstream 750 configured to implement a stepwise decoded refresh (GDR) technique 700. As used herein, the video bitstream 750 may also be referred to as a coded video bitstream, a bitstream, or a variation thereof. As shown in Figure 7, the bitstream 750 includes a sequence parameter set (SPS) 752, a picture parameter set (PPS) 754, a slice header 756, and image data 758. The bitstream 750, SPS 752, PPS 754, and slice header 756 in Figure 7 are analogous to the bitstream 550, SPS 552, PPS 554, and slice header 556 in Figure 5. Therefore, for brevity, a description of these elements will not be repeated.

[0117] The image data 758 in Figure 7 includes data related to the image or video to be encoded or decoded. The image data 758 may simply be referred to as the payload or data carried in the bitstream 750. In one embodiment, the image data 758 includes a CVS 708 (or CLVS) which includes a GDR picture 702, one or more subsequent pictures 704, and a sequence picture ending picture 706. In one embodiment, the GDR picture 702 is referred to as the CVSS picture. The decoding process of the CVS 508 always begins with the GDR picture 702.

[0118] As shown in Figure 7, the GDR picture 702, the subsequent picture 704, and the sequence end picture 706 in CVS708 are each contained within their own VCL NAL unit 730. The set of NAL units 730 in CVS708 is sometimes referred to as an access unit.

[0119] In the latest draft specification of VVC, the output of a picture preceding an IRAP picture is defined as follows: A preceding picture for an IRAP picture (e.g., a previously decoded picture) refers to a picture that 1) is decoded earlier than the IRAP picture, 2) is instructed to be output, 3) is present in the decoded picture buffer (DPB) at the start of IRAP picture decoding, and 4) is not output at the start of IRAP picture decoding. As used herein, a preceding picture may be referred to as a previously decoded picture.

[0120] The slice header syntax includes the syntax element no_output_of_prior_pics_flag for IDR and CRA pictures. Its meaning is as follows:

[0121] The no_output_of_prior_pics_flag affects the output of previously decoded pictures in the decoded picture buffer after decoding an IDR picture that is not the first picture in the bitstream, as specified in Annex C of VVC Draft 5.

[0122] Section C.3.2 of VVC Draft 5 (Deletion of pictures from the DPB before decoding the current picture) contains the following text:

[0123] The following ordered steps apply when the current picture is an IRAP picture that is not picture0 and has a NoIncorrectPicOutputFlag equal to 1.

[0124] 1. The variable NoOutputOfPriorPicsFlag is derived for the decoder under test as follows:

[0125] If the current picture is a CRA picture, NoOutputOfPriorPicsFlag is set to 1 (regardless of the value of no_output_of_prior_pics_flag).

[0126] Otherwise, pic_width_in_luma_samples, pic_height_in_luma_samples, croma_format_idc, separate_colour_plane_flag, bit_depth_luma_minus8, bit_depth_chroma_minus8, or sps_max_dec_pic_buffering_minus1[HighestTid] derived from the active SPS will be used to determine pic_width_in_luma_samples for the preceding picture. If the value of es, pic_height_in_luma_samples, chroma_format_idc, separate_colour_plane_flag, bit_depth_luma_minus8, bit_depth_chroma_minus8, or sps_max_dec_pic_buffering_minus1[HighestTid] is different, the decoder under test may (but should not) set NoOutputOfPriorPicsFlag to 1, regardless of the value of no_output_of_pics_flag.

[0127] Note - Under these conditions, it is preferable to set NoOutputOfPriorPicsFlag to no_output_of_prior_pics_flag, however, in this case, the decoder under test is permitted to set NoOutputOfPriorPicsFlag to 1.

[0128] Otherwise, NoOutputOfPriorPicsFlag is set to equal no_output_of_prior_pics_flag.

[0129] The NoOutputOfPriorPicsFlag value derived for the decoder under test is applied to the hypothetical reference decoder (HRD). When the NoOutputOfPriorPicsFlag value is equal to 1, all picture memory buffers within the DPB are emptied with no output for the pictures they contain, and the DPB's fullness is set to 0.

[0130] Section C.5.2.2 (Outputting and Deleting Pictures from DPB) of VVC Draft 5 contains the following text:

[0131] The following ordered steps apply when the current picture is an IRAP picture that is not picture0 and has a NoIncorrectPicOutputFlag equal to 1.

[0132] 1. The variable NoOutputOfPriorPicsFlag is derived for the decoder under test as follows:

[0133] If the current picture is a CRA picture, NoOutputOfPriorPicsFlag is set to 1 (regardless of the value of no_output_of_prior_pics_flag).

[0134] Otherwise, pic_width_in_luma_samples, pic_height_in_luma_samples, croma_format_idc, separate_colour_plane_flag, bit_depth_luma_minus8, bit_depth_chroma_minus8, or sps_max_dec_pic_buffering_minus1[HighestTid] derived from the active SPS will be used to determine pic_width_in_luma_samples for the preceding picture. If the value of es, pic_height_in_luma_samples, chroma_format_idc, separate_colour_plane_flag, bit_depth_luma_minus8, bit_depth_chroma_minus8, or sps_max_dec_pic_buffering_minus1[HighestTid] is different, the decoder under test may (but should not) set NoOutputOfPriorPicsFlag to 1, regardless of the value of no_output_of_pics_flag.

[0135] Note - Under these conditions, it is preferable to set NoOutputOfPriorPicsFlag to no_output_of_prior_pics_flag, however, in this case, the decoder under test is permitted to set NoOutputOfPriorPicsFlag to 1.

[0136] Otherwise, NoOutputOfPriorPicsFlag is set to equal no_output_of_prior_pics_flag.

[0137] 2. The NoOutputOfPriorPicsFlag value derived for the decoder under test is applied to the HRD as follows:

[0138] If NoOutputOfPriorPicsFlag is equal to 1, all picture storage buffers within the DPB are emptied without outputting the pictures they contain, and the fullness of the DPB is set to 0.

[0139] Otherwise (NoOutputOfPriorPicsFlag is equal to 0), all picture storage buffers containing pictures marked as "not needed for output" and "not used for reference" are emptied (without output), all non-empty picture storage buffers in the DPB are emptied by repeatedly calling the "bumping" process specified in Section C.5.2.4, and the DPB fullness is set to equal to 0.

[0140] The problems with existing designs were discussed.

[0141] In the latest draft specification for VVC, for CRA pictures where NoIncorrectPicOutputFlag is equal to 1 (i.e., CRA pictures that start a new CVS), the value of NoOutputOfPriorPicsFlag is set to equal to 1 regardless of the value of no_output_of_prior_pics_flag, so the value of no_output_of_prior_pics_flag is not used. In other words, the picture before each CRA picture that starts a CVS is not output. However, as with IDR pictures, outputting / displaying the previous picture can provide a more continuous playback and thus a better user experience, as long as the DPB does not overflow when decoding the picture that starts a new CVS and the subsequent pictures in the decoding order.

[0142] To solve the problems discussed above, this disclosure provides the following inventive aspects: The value of no_output_of_prior_pics_flag is used in the specification of outputting the picture prior to each CRA picture that is not the first picture in the bitstream and starts a new CVS. This enables more continuous playback and, therefore, a better user experience.

[0143] Furthermore, this disclosure also applies to other types of pictures that initiate a new CVS, such as the Stepped Random Access (GRA) picture currently specified in the latest VVC draft specification. In one embodiment, GRA picture may refer to or be synonymous with GDR picture.

[0144] For example, when decoding a video bitstream, a flag corresponding to a clean random access (CRA) picture is signaled in the bitstream. The flag specifies whether a decoded picture in the decoded picture buffer that is decoded earlier than the CRA picture is output when the CRA picture starts a new coded video sequence. That is, the previous picture is output when the value of the flag indicates that the previous picture should be output (for example, when the value is equal to 0). In one embodiment, the flag is specified as no_output_of_prior_pics_flag.

[0145] As another example, when decoding a video bitstream, a flag corresponding to a Stepwise Random Access (GRA) picture is signaled in the bitstream. The flag specifies whether a decoded picture in a decoded picture buffer that is decoded earlier than the GRA picture is output when the GRA picture starts a new coded video sequence. That is, the previous picture is output when the value of the flag indicates that the previous picture should be output (for example, when the value is equal to 0). In one embodiment, the flag is specified as no_output_of_prior_pics_flag.

[0146] Disclosed herein is a technique for outputting the previous picture (e.g., a previously decoded picture) in the decoded picture buffer (DPB) when a random access point picture other than an instantaneous decoder refresh (IDR) picture (e.g., a clean random access (CRA) picture, a stepped random access (GRA) picture, or a stepped decode refresh (GDR) picture, CVSS picture, etc.) is encountered in the decoding order. By clearing the DPB of previously decoded pictures when a random access point picture is reached, the DPB is prevented from overflowing, and more continuous playback is facilitated. Thus, the coder / decoder (also known as "codec") in video coding is improved compared to current codecs. In practice, the improved video coding process provides a better user experience when video is sent, received, and / or viewed.

[0147] Figure 8 shows one embodiment of method 800 for decoding a coded video bitstream implemented by a video decoder (e.g., video decoder 30). Method 800 may be performed after the decoded bitstream has been received directly or indirectly from a video encoder (e.g., video encoder 20). Method 800 improves the decoding process by clearing the DPB before the current picture is decoded when a random access point picture is encountered. Method 800 prevents DPB overflow and promotes more continuous playback. Thus, in practice, the performance of the codec is improved, which leads to a better user experience.

[0148] In block 802, the video decoder receives a coded video bitstream (e.g., bitstream 750). The coded video bitstream includes a Stepwise Decode Refresh (GDR) picture and a first flag having a first value. In one embodiment, the GDR picture is not the first picture in the video bitstream. In one embodiment, the first flag is specified as no_output_of_prior_pics_flag. In one embodiment, the GDR picture is placed in a Video Coding Layer (VCL) Network Abstraction Layer (NAL) unit having a Stepwise Decode Refresh (GDR) Network Abstraction Layer (NAL) unit type (GDR_NUT).

[0149] In block 804, the video decoder sets the second value of the second flag to be equal to the first value of the first flag. In one embodiment, the second flag is specified as NoOutputOfPriorPicsFlag. In one embodiment, the second flag is internal to the decoder.

[0150] In block 806, the video decoder clears any previously decoded pictures corresponding to the GDR picture from the DPB based on a second flag having a second value. In one embodiment, after the GDR picture is decoded, the previously decoded pictures are cleared from the DPB. That is, the video decoder removes the previously decoded pictures from the picture storage buffer in the DPB. In one embodiment, the previously decoded pictures are not output or displayed when the previously decoded pictures are removed from the DPB. In one embodiment, the DPB fullness parameter is set to zero when the first flag is set to a first value. The "DPB fullness" parameter indicates how many pictures are held in the DPB. Setting the DPB fullness parameter to zero indicates that the DPB is empty.

[0151] In block 808, the video decoder decodes the current picture after the DPB is empty. In one embodiment, the current picture is from the same CVS as the CRA picture and is acquired or encountered after the CRA in the decoding order. In one embodiment, the image generated based on the current picture is displayed to the user of an electronic device (e.g., a smartphone, tablet, laptop, personal computer, etc.).

[0152] Figure 9 shows one embodiment of method 900 for encoding a video bitstream implemented by a video encoder (e.g., video encoder 20). Method 900 may be performed when a picture (e.g., from a video) is encoded into a video bitstream and sent toward a video decoder (e.g., video decoder 30). Method 900 improves the encoding process by instructing the video decoder to empty the DPB before decoding the current picture when it encounters a random access point picture. Method 900 prevents DPB overflow and promotes more continuous playback. Thus, as a practical matter, the performance of the codec is improved, which leads to a better user experience.

[0153] In block 902, the video encoder determines the random access point of the video sequence. In block 904, the video encoder encodes a Stepwise Decode Refresh (GDR) picture into the video sequence at the random access point. In one embodiment, the GDR picture is not the first picture in the video bitstream. In one embodiment, the GDR picture is located in a Video Coding Layer (VCL) Network Abstraction Layer (NAL) unit having a Stepwise Decode Refresh (GDR) Network Abstraction Layer (NAL) unit type (GDR_NUT).

[0154] In block 906, the video encoder sets a flag to a first value that instructs the video decoder to empty any previously decoded pictures from the decoded picture buffer (DPB). In one embodiment, the video decoder is instructed to empty any previously decoded pictures from the DPB after the GDR picture has been decoded. In one embodiment, the flag is specified as no_output_of_prior_pics_flag. In one embodiment, when the flag is set to the first value, the video encoder instructs the video decoder to set the DPB fullness parameter to zero. In one embodiment, the first value of the flag is 1.

[0155] In block 908, the video encoder generates a video bitstream containing a video sequence with GDR pictures at random access points, and flags. In block 910, the video encoder stores the video bitstream for transmission toward the video decoder.

[0156] The following syntax and meaning may be used to implement the embodiments disclosed herein. The following description is relative to the base text, which is the latest VVC draft specification. In other words, only deltas are described, but the text of the base text not mentioned below remains applicable. Text added to the base text is shown in bold, and text deleted is shown in italics (hereinafter, bold parts may be represented by the part enclosed by (start of bold) and (end of bold), and italic parts by the part enclosed by (start of italics) and (end of italics)).

[0157] General slice header syntax (VVC 7.3.5.1). [Table 1]

[0158] The general meaning of slice header (VVC 7.4.6.1).

[0159] If present, the values ​​of the slice header syntax elements slice_pic_parameter_set_id, slice_pic_order_cnt_lsb, no_output_of_prior_pics_flag, and slice_temporal_mvp_enabled_flag shall be the same in all slice headers of the coded picture.

[0160] ...

[0161] The no_output_of_prior_pics_flag affects the output of previously decoded pictures in the decoded picture buffer after decoding an IDR picture (italic) (italic) (bold) CVSS picture (bold) that is not the first picture in the bitstream specified in Annex C.

[0162] ...

[0163] Before decrypting the current picture, delete the picture from the DPB (VVC C.3.2).

[0164] ...

[0165] The following ordered steps apply when the current picture is an IRAP picture (italic start) NoIncorrectPicOutputFlag equal to 1 (italic end) CVSS picture that is not Picture 0.

[0166] 1. The variable NoOutputOfPriorPicsFlag is derived for the decoder under test as follows:

[0167] (Italic start) If the current picture is a CRA picture, NoOutputOfPriorPicsFlag is set to 1 (regardless of the value of no_output_of_prior_pics_flag). (Italic end)

[0168] (Italic start) Otherwise, (Italic end) pic_width_in_luma_samples, pic_height_in_luma_samples, chroma_format_idc, separate_colour_plane_flag, bit_depth_luma_minus8, bit_depth_chroma_minus8, or sps_max_dec_pic_buffering_minus1[HighestTid] derived from the active SPS for the preceding picture are respectively pic_width_in_luma_samples, pic_height_in_luma_samples, chroma_format_idc, separate_colour_plane_flag, bit_depth_luma_minus8, bit_depth_chroma_minus8, or sps_max_dec_pic_buffering_ If it differs from the value of minus1[HighestTid], the decoder under test may (but should not) set NoOutputOfPriorPicsFlag to 1, regardless of the value of no_output_of_pics_flag.

[0169] Note - Under these conditions, it is preferable to set NoOutputOfPriorPicsFlag to no_output_of_prior_pics_flag, however, in this case, the decoder under test is permitted to set NoOutputOfPriorPicsFlag to 1.

[0170] Otherwise, NoOutputOfPriorPicsFlag is set to equal no_output_of_prior_pics_flag.

[0171] 2. The value of NoOutputOfPriorPicsFlag derived for the decoder under test is applied to the HRD, and when the value of NoOutputOfPriorPicsFlag is equal to 1, all picture memory buffers in the DPB are emptied with no output for the pictures they contain, and the fullness of the DPB is set to 0.

[0172] Figure 10 is a schematic diagram of a video coding device 1000 (e.g., a video encoder 20 or a video decoder 30) according to one embodiment of the present disclosure. The video coding device 1000 is suitable for implementing the disclosed embodiments described herein. The video coding device 1000 includes an inlet port 1010 and a receiver unit (Rx) 1020 for receiving data, a processor, logic unit, or central processing unit (CPU) 1030 for processing the data, a transmitter unit (Tx) 1040 and an exit port 1050 for transmitting data, and a memory 1060 for storing data. The video coding device 1000 may also include optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the inlet port 1010, receiver unit 1020, transmitter unit 1040, and exit port 1050 for the input and output of optical or electrical signals.

[0173] The processor 1030 is implemented by hardware and software. The processor 1030 may be implemented as one or more CPU chips, cores (e.g., a multi-core processor), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 1030 communicates with the input port 1010, the receiver unit 1020, the transmitter unit 1040, the output port 1050, and the memory 1060. The processor 1030 includes a coding module 1070. The coding module 1070 implements the embodiments disclosed above. For example, the coding module 1070 implements, processes, prepares, or provides various codec functions. Thus, including the coding module 1070 provides a substantial improvement to the functionality of the video coding device 1000 and results in the conversion of the video coding device 1000 to different states. Alternatively, the coding module 1070 is implemented as an instruction stored in memory 1060 and executed by processor 1030.

[0174] The video coding device 1000 may also include an input and / or output (I / O) device 1080 for communicating data with the user. The I / O device 1080 may include output devices such as a display for showing video data and a speaker for outputting audio data. The I / O device 1080 may also include input devices such as a keyboard, mouse, or trackball, and / or corresponding interfaces for interacting with such output devices.

[0175] Memory 1060 may include one or more disks, tape drives, and solid-state drives, and is used as an overflow data storage device to store a program when such a program is selected for execution, and to store instructions and data read during program execution. Memory 1060 may be volatile and / or non-volatile, and may be read-only memory (ROM), random-access memory (RAM), ternarily content-addressable memory (TCAM), and / or static random-access memory (RSAM).

[0176] Figure 11 is a schematic diagram of an embodiment of the coding means 1100. In one embodiment, the coding means 1100 is implemented in a video coding device 1102 (e.g., a video encoder 20 or a video decoder 30). The video coding device 1102 includes a receiving means 1101. The receiving means 1101 is configured to receive a picture to encode or a bitstream to decode. The video coding device 1102 includes a transmitting means 1107 coupled to the receiving means 1101. The transmitting means 1107 is configured to transmit a bitstream to a decoder or to transmit a decoded image to a display means (e.g., one of the I / O devices 1080).

[0177] The video coding device 1102 includes a storage means 1103. The storage means 1103 is coupled to at least one of the receiving means 1101 or the transmitting means 1107. The storage means 1103 is configured to store instructions. The video coding device 1102 also includes a processing means 1105. The processing means 1105 is coupled to the storage means 1103. The processing means 1105 is configured to execute instructions stored in the storage means 1103 in order to perform the method disclosed herein.

[0178] Furthermore, it should be understood that the steps of the exemplary methods described herein do not necessarily have to be performed in the order described, and that the order of the steps of such methods is merely illustrative. Similarly, additional steps may be included in such methods, and certain steps may be omitted or combined in a manner consistent with various embodiments of the present disclosure.

[0179] While several embodiments are 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. These examples are illustrative and not limiting, and their intent is not limited to the details given herein. For example, various elements or components may be combined or integrated into another system, and certain features may be omitted or not implemented.

[0180] In addition, technologies, systems, subsystems, and methods described and illustrated individually or separately in various embodiments may be combined with or integrated with other systems, modules, technologies, or methods without departing from the scope of this disclosure. Other items shown or discussed as being coupled, directly coupled, or communicating with one another may be indirectly coupled or communicated through some interfaces, devices, or intermediate components, electrically, mechanically, or otherwise. Other examples of modifications, substitutions, and alterations are evident to those skilled in the art and can be made without departing from the spirit and scope disclosed herein.

Claims

1. A method for storing an encoded video bitstream, The method involves storing the coded video bitstream on a non-temporary computer-readable recording medium, wherein the coded video bitstream includes coded stepwise decoded refresh (GDR) pictures and a first flag having a first value, the coded GDR picture being not the first picture of the coded video bitstream, and the first flag being specified as no_output_of_prior_pics_flag. The decoder's processor decodes the coded video bitstream to obtain the first flag and sets the second value of the second flag to be equal to the first value of the first flag. The processor clears any previously decoded picture corresponding to the GDR picture from the decoded picture buffer (DPB) based on the second flag having the second value, The processor includes decoding the current picture after the DPB has become empty, The second flag is specified as NoOutputOfPriorPicsFlag.

2. The method according to claim 1, wherein the coded GDR picture is disposed in a video coding layer (VCL) NAL unit having a GDR network abstraction layer (NAL) unit type (GDR_NUT).

3. The method according to claim 1 or 2, wherein when the first flag is set to the first value, the processor of the decoder sets the DPB fullness parameter to zero.

4. The method according to any one of claims 1 to 3, wherein the DPB is emptied after the coded GDR picture has been decoded.

5. The method according to claim 3, wherein the DPB fullness parameter indicates how many pictures are held within the DPB.

6. The method according to any one of claims 1 to 4, wherein the first value of the first flag is 1.

7. The method according to any one of claims 1 to 6, wherein the coded video bitstream further comprises a sequence parameter set (SPS) and / or a picture parameter set (PPS).

8. A system comprising the processor that performs the method according to any one of claims 1 to 7.

9. A decoding device, A receiver configured to receive a coded video bitstream, A memory coupled to the receiver, wherein the memory stores instructions, The processor is coupled to the memory, and the processor controls the decoding device. Receiving the coded video bitstream, wherein the coded video bitstream includes coded stepwise decoded refresh (GDR) pictures and a first flag having a first value, and the coded GDR picture is not the first picture of the coded video bitstream. Setting a second value of a second flag equal to the first value of the first flag, wherein the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag, Based on the second flag having the second value, any previously decoded picture corresponding to the GDR picture is cleared from the decoded picture buffer (DPB), The system is configured to execute the instruction to decode the current picture after the DPB becomes empty, The coded video bitstream is further decoded by a decoding device comprising a sequence parameter set (SPS) and / or a picture parameter set (PPS).

10. The decoding device according to claim 9, further comprising a display configured to display an image generated based on the current picture.

11. The decoding device according to claim 9 or 10, wherein when the first flag is set to the first value, the processor of the decoding device sets the DPB fullness parameter to zero.

12. The decoding device according to claim 11, wherein the DPB fullness parameter indicates how many pictures are held in the DPB.

13. A decoding method implemented by a video decoder, The video decoder receives a coded video bitstream, wherein the coded video bitstream includes a coded stepwise decoded refresh (GDR) picture and a first flag having a first value, the coded GDR picture is not the first picture in the coded video bitstream, and the coded video bitstream further includes a sequence parameter set (SPS) and / or a picture parameter set (PPS). The video decoder sets a second value of the second flag equal to the first value of the first flag, wherein the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag. The video decoder clears any previously decoded picture corresponding to the GDR picture from the decoded picture buffer (DPB) based on the second flag having the second value, A method comprising decoding the current picture after the DPB has become empty using the video decoder.

14. The method according to claim 13, wherein the coded GDR picture is disposed in a video coding layer (VCL) NAL unit having a GDR network abstraction layer (NAL) unit type (GDR_NUT).

15. The method according to claim 13 or 14, further comprising setting the DPB fullness parameter to zero when the first flag is set to the first value.

16. The method according to any one of claims 13 to 15, wherein the DPB is emptied after the coded GDR picture has been decoded.

17. The method according to any one of claims 13 to 16, wherein the first value of the first flag is 1.

Images