Output of previous picture for picture starting new coded video sequence in video coding

Abstract

To provide a method for decoding a coded video bitstream and a corresponding method for encoding.SOLUTION: A method includes receiving a coded video bitstream including a first flag having a first value and a clean random access (CRA) picture, setting a second value of a second flag to be equal to the first value of the first flag, emptying, by a video decoder, a decoded picture buffer (DPB) of any previously decoded pictures on the basis of the second flag having the second value, and decoding a current picture after the DPB is emptied.SELECTED DRAWING: Figure 8

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This patent application claims priority based on U.S. Provisional Patent Application No. 62 / 843,991, titled "Output of Previous Picture for a Picture Initiating a Newly Encoded Video Sequence in Video Coding", filed on May 6, 2019 by Ye - Kui Wang, the content of which is hereby incorporated by reference in its entirety.

[0002] [Technical Field] Generally, this disclosure describes a plurality of techniques for supporting the output of previously decoded pictures during video coding. More specifically, this disclosure enables outputting a previously decoded picture corresponding to a random access point picture that initiates a coded video sequence (CVS) from a buffer of decoded pictures.

Background Art

[0003] Even the amount of video data required to depict a relatively short video can be quite large, and that amount of video data can be problematic when the data is being streamed or otherwise communicated over a communication network with limited bandwidth capacity. Thus, video data is generally compressed before being communicated over modern communication networks. Since memory resources can be limited, the size of the video can also be a problem when storing the video on a storage device. Video compression devices typically 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 the digital video image. 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 image quality are desirable because network resources are limited and the demand for higher video quality is constantly increasing.

SUMMARY OF THE INVENTION

[0004] A first aspect relates to a method of decoding implemented by a video decoder. The method includes receiving, by the video decoder, a coded video bitstream, the coded video bitstream including a first flag having a first value and a clean random access (CRA) picture; setting, by the video decoder, a second value of a second flag to be equal to the first value of the first flag; emptying, by the video decoder, any previously decoded pictures from a decoded picture buffer (DPB) based on the second flag having the second value; and decoding, by the video decoder, a current picture after the DPB has been emptied.

[0005] When encountering in decoding order 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.), the method provides techniques for output of previous pictures (e.g., previously decoded pictures, etc.) in the buffer of decoded pictures (DPB). Emptying the previously decoded pictures from the DPB when reaching a random access point picture prevents the DPB from causing an overflow and promotes more continuous playback. Thus, the coder / decoder (also known as a "codec") in video coding is improved compared to the current codec. As a practical matter, when video is transmitted, received, and / or viewed, the improved video coding process provides a better user experience to the user.

[0006] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the CRA picture is not the first picture of the coded video bitstream.

[0007] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide a step of setting a DPB fullness parameter to 0 when the first flag is set to the first value.

[0008] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag.

[0009] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the DPB is emptied after the CRA picture is decoded.

[0010] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide a step of displaying an image generated based on the current picture.

[0011] A second aspect relates to a method of encoding implemented by a video encoder. The method includes: determining, by the video encoder, a random access point for a video sequence; encoding, by the video encoder, a clean random access (CRA) picture to be the video sequence at the random access point; setting, by the video encoder, a flag to a first value and instructing a video decoder to empty any previously decoded pictures from a decoded picture buffer (DPB); generating, by the video encoder, a video bitstream including the video sequence having the CRA picture at the random access point and the flag; and storing, by the video encoder, the video bitstream for transmission to the video decoder.

[0012] When encountering a random access point picture (such as a clean random access (CRA) picture, a gradual random access (GRA) picture, or a gradual decoding refresh (GDR) picture, a CVSS picture, etc.) other than an instantaneous decoder refresh (IDR) picture in decoding order, the method provides a technique for output of a previous picture (such as a previously decoded picture, etc.) in a buffer of decoded pictures (DPB). Emptying the previously decoded pictures from the DPB when reaching a random access point picture prevents the DPB from causing an overflow and promotes more continuous playback. Accordingly, a coder / decoder (also known as a "codec") in video coding is improved compared to a current codec. As a practical matter, when video is transmitted, received, and / or viewed, the improved video coding process provides a better user experience to the user.

[0013] Optionally, in any of the plurality of preceding aspects, another implementation of that aspect provides that the CRA picture is not the first picture of the video bitstream and that the video decoder is instructed to empty the DPB after the CRA picture is decoded.

[0014] Optionally, in any of the plurality of preceding aspects, another implementation of that aspect provides a step of instructing the video decoder to set a DPB fullness parameter to 0 when the flag is set to the first value.

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

[0016] Optionally, in any of a plurality of preceding aspects, other implementations of that aspect provide that the first value of the flag is 1.

[0017] A third aspect relates to a decoding device. The decoding device includes a receiver configured to receive a coded video bitstream, a memory coupled to the receiver, the memory storing instructions, and a processor coupled to the memory. The processor executes the instructions to cause the decoding device to receive the coded video bitstream, the coded video bitstream including a first flag having a first value and a clean random access (CRA) picture, set a second value of a second flag to be equal to the first value of the first flag, clear any previously decoded picture from a decoded picture buffer (DPB) based on the second flag having the second value, and decode a current picture after the DPB is cleared.

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

[0019] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the CRA picture is not the first picture of the coded video bitstream.

[0020] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag.

[0021] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide a display configured to display an image generated based on the current picture.

[0022] A fourth aspect relates to an encoding device. The encoding device includes a memory for storing instructions, and a processor coupled to the memory. The processor implements the instructions such that the encoding device determines a random access point for a video sequence, encodes a clean random access (CRA) picture to form the video sequence at the random access point, sets a flag to a first value, and instructs a video decoder to clear any previously decoded pictures from a decoded picture buffer (DPB), and generates the video bitstream including the video sequence having the CRA picture at the random access point and the flag. A transmitter is coupled to the processor and is configured to transmit the video bitstream to a video decoder.

[0023] When encountering in decoding order 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.), the encoding device provides techniques for output of previous pictures (e.g., previously decoded pictures, etc.) in a decoded picture buffer (DPB). Clearing previously decoded pictures from the DPB when reaching a random access point picture prevents the DPB from causing an overflow and promotes more continuous playback. Thus, the coder / decoder (also known as a "codec") in video coding is improved compared to current codecs. As a practical matter, when video is transmitted, received, and / or viewed, the improved video coding process provides a better user experience to the user.

[0024] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the CRA picture is not the first picture of the video bitstream.

[0025] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the flag is specified as no_output_of_prior_pics_flag.

[0026] Optionally, in any of the plurality of preceding aspects, other implementations of that aspect provide that the memory stores the bitstream before the transmitter transmits the bitstream to the video decoder.

[0027] A fifth aspect relates to a coding apparatus. The coding apparatus includes a receiver configured to receive a picture for encoding or a bitstream for decoding, a transmitter coupled to the receiver, the transmitter being configured to transmit the bitstream to a decoder or transmit a 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 instructions stored in the memory to execute any of the methods disclosed herein.

[0028] When encountering in decoding order 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.), the coding device provides a technique for output of a previous picture (e.g., a previously decoded picture, etc.) in a buffer of decoded pictures (DPB). Emptying the previously decoded pictures from the DPB when reaching a random access point picture prevents the DPB from causing an overflow and promotes more continuous playback. Thus, the coder / decoder (also known as a "codec") in video coding is improved compared to a current codec. As a practical matter, when video is transmitted, received, and / or viewed, the improved video coding process provides a better user experience to the user.

[0029] Optionally, in any of a plurality of preceding aspects, other implementations of that aspect provide a display configured to display an image.

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

[0031] When encountering random access point pictures (such as clean random access (CRA) pictures, gradual random access (GRA) pictures, or gradual decoding refresh (GDR) pictures, CVSS pictures, etc.) other than instant decoder refresh (IDR) pictures in decoding order, the system provides a technique for outputting previous pictures (such as previously decoded pictures, etc.) in the buffer of decoded pictures (DPB). Emptying the previously decoded pictures from the DPB when reaching a random access point picture prevents the DPB from causing an overflow and promotes more continuous playback. Therefore, the coder / decoder (also known as the "codec") in video coding is improved compared to the current codec. As a practical matter, when video is transmitted, received, and / or viewed, the improved video coding process provides a better user experience to the user.

[0032] The seventh aspect relates to means for coding. The means for coding includes receiving means configured to receive a picture for encoding or a bitstream for decoding, transmission means coupled to the receiving means, wherein the transmission means is configured to transmit the bitstream to decoding means or transmit the decoded image to display means, storage means coupled to at least one of the receiving means or the transmission means, wherein the storage means is configured to store instructions, and processing means coupled to the storage means, wherein the processing means is configured to execute the instructions stored in the storage means to execute any of the methods disclosed herein.

[0033] When encountering random access point pictures (such as clean random access (CRA) pictures, gradual random access (GRA) pictures, or gradual decoding refresh (GDR) pictures, CVSS pictures, etc.) other than instant decoder refresh (IDR) pictures in decoding order, the means for coding them provides techniques for output of previous pictures (such as previously decoded pictures, etc.) in the buffer of decoded pictures (DPB). Emptying the previously decoded pictures from the DPB when reaching a random access point picture prevents the DPB from causing an overflow and promotes more continuous playback. Therefore, the coder / decoder (also known as the "codec") in video coding is improved compared to the current codec. As a practical matter, when video is transmitted, received, and / or viewed, the improved video coding process provides a better user experience to the user.

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

[0035] These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and the claims.

Brief Description of the Drawings

[0036] To more fully understand this disclosure, the following brief description is presented in connection with a plurality of accompanying drawings and the detailed description, in which like reference numerals represent like parts.

[0037]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

[0038] Initially, the following provides one exemplary implementation of one or more of a plurality of embodiments, but it should be understood that any number of techniques may be used to implement the disclosed systems and / or methods, whether currently known or existing. This disclosure should in no way be limited to the exemplary implementations, drawings, and techniques described below, which include a plurality of exemplary designs and implementations described and explained herein, but may be modified within the scope of the invention as set forth in the appended claims, together with all equivalents of the invention as set forth in the claims.

[0039] FIG. 1 is a block diagram showing one exemplary coding system 10, which can utilize the video coding techniques described herein. As shown in FIG. 1, the coding system 10 includes a source device 12 that provides encoded video data to be decoded by a destination device 14 at a later time. 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 the destination device 14 may include any of a wide range of devices, including desktop computers, notebook computers (such as laptop computers), tablet computers, set-top boxes, telephone handsets such as so-called "smart" phones, so-called "smart" pads, televisions, cameras, display devices, digital media players, video game consoles, or video streaming devices. In some cases, the source device 12 and the destination device 14 may be capable of supporting wireless communication.

[0040] The destination device 14 may receive the encoded video data that is decoded via the computer-readable medium 16. The computer-readable medium 16 may include any type of medium or device that is capable of moving the encoded video data from the source device 12 to the destination device 14. In one 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 communication medium 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 also include other devices that are useful for facilitating communication from the source device 12 to the destination device 14 such as routers, switches, base stations, or the like.

[0041] In some of the plurality of examples, data encoded in the output interface 22 may be output to the storage device. Similarly, it is possible to access the data encoded in the input interface from the storage device. The storage device may include various distributed data storage media or locally accessible data storage media such as a hard drive, a Blu-ray disk, a digital video disk (DVD), a compact disk read-only memory (CD-ROM), a flash memory, a volatile memory or a non-volatile memory, or any other suitable digital storage medium for storing the encoded video data. In a further example, the storage device may correspond to a file server or other intermediate storage device, and those file servers or other intermediate storage devices are capable of storing the encoded video generated by the source device 12. The destination device 14 can access the video data stored in the storage device by streaming or downloading. The file server may be any type of server, and any type of that server is capable of storing the encoded video data and transmitting the encoded video data to the destination device 14. Exemplary file servers include a web server (for example, for a certain website), a file transfer protocol (FTP) server, a network attached storage (NAS) device, or a local disk drive. The destination device 14 can access the encoded video data thereof by any standard data connection including an Internet connection. This standard data connection may include a wireless channel (such as a Wi-Fi connection, for example), a wired connection (such as a digital subscriber line (DSL), a cable modem, etc.), or a combination of both a wireless channel and a wired connection suitable for accessing the encoded video data stored in the file server. The transmission of the encoded video data from the storage device may be a streaming transmission, a download transmission, or a combination thereof.

[0042] The multiple technologies of this disclosure are not necessarily limited to wireless applications or settings. They can be applied to video coding that supports 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 over HTTP (DASH), digital video encoded in a data storage medium, decoding of digital video stored in a data storage medium, or other applications. In some of the multiple examples, the coding system 10 may be configured to support applications such as video streaming, video playback, video broadcast, and / or video phone by supporting one-way video transmission or two-way video transmission.

[0043] In the example of FIG. 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 multiple technologies for video coding. In other examples, the source device and the 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, since the destination device 14 does not include an integrated display device, it is possible to provide an interface to an external display device.

[0044] The illustrated coding system 10 of FIG. 1 is merely one example. The techniques for video coding may be performed by any digital video encoding device and / or decoding device. The plurality of techniques of this disclosure are generally performed by a video coding device, but the plurality of techniques may also typically be performed by a video encoder / decoder, typically referred to as a "CODEC". Further, the plurality of techniques of this disclosure may also be performed by a video processor. The video encoder and / or video decoder may be a graphics processing unit or a similar device.

[0045] The source device 12 and the destination device 14 are merely examples of such a plurality of coding devices that generate video data coded by the source device 12 for transmission to the destination device 14. In some of the plurality of examples, the source device 12 and the destination device 14 may operate in a substantially symmetric manner, whereby each of the source device 12 and the destination device 14 includes a video encoding component and a video decoding component. Thus, the coding system 10 can support one-way or two-way video transmission between the plurality of video devices 12 and 14, for example, for video streaming, video playback, video broadcast, or video telephony.

[0046] The video source 18 of the source device 12 may include a video capture device such as a video camera, a video archive that houses 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 video generated by a computer.

[0047] 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. On the other hand, as mentioned above, the techniques described in this disclosure may generally be applicable to video coding and may also be applied to wireless applications and / or wired applications. In each case, the video to be captured, the pre-captured video, or the video generated by a computer may be encoded by the video encoder 20. The encoded video information may then be output by the output interface 22 to the computer-readable medium 16.

[0048] The computer-readable medium 16 may include a temporary medium such as a wireless broadcast transmission or a wired network transmission, or a storage medium (i.e., a non-temporary medium) such as a hard disk, a flash drive, a compact disk, a digital video disk, a Blu-ray disk, or other computer-readable media. In some of the plurality of examples, a network server (not shown) may receive the encoded video data from the source device 12 and provide the encoded video data to the destination device 14, for example, by network transmission. Similarly, a computing device of a media manufacturing facility such as a disk engraving facility may receive the encoded video data from the source device 12 and manufacture a disk containing the encoded video data. Therefore, the computer-readable medium 16 may be understood to include one or more of various forms of computer-readable media in various examples.

[0049] The input interface 28 of the destination device 14 receives information from the computer-readable medium 16. That information of the computer-readable medium 16 may include syntax information defined by the video encoder 20, and that syntax information is also used by the video decoder 30, and that syntax information includes syntax elements that describe the characteristics and / or processing of blocks and other coded units such as, for example, multiple picture groups (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), a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or other types of display devices.

[0050] Video encoder 20 and video decoder 30 may operate in accordance with video coding standards such as the currently under - development High Efficiency Video Coding (HEVC) standard, and may conform to the HEVC Test Model (HM). Alternatively, video encoder 20 and video decoder 30 may operate in accordance with other proprietary or industry standards such as the Moving Picture Experts Group (MPEG) 4, Part 10, Advanced Video Coding (AVC), H.265 / HEVC, or the ITU - T H.264 standard, which is referred to as an extension of such standards. On the other hand, the plurality of techniques of this disclosure are 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 FIG. 1, in some of the plurality of aspects, video encoder 20 and video decoder 30 may each be integrated with an audio encoder and decoder, and may include a suitable multiplexer - demultiplexer (MUX - DEMUX) unit or other hardware and software to process the encoding of both audio and video in a common data stream or individual data streams. When applicable, the MUX - DEMUX unit may conform to the ITU H.223 multiplexer protocol, or other protocols such as the User Datagram Protocol (UDP).

[0051] Video encoder 20 and video decoder 30 may each be implemented as any of a variety of 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 a plurality of those techniques are implemented partially by software, the device may store the plurality of instructions for the software in a suitable and non-transitory computer-readable medium and execute the plurality of instructions in hardware using one or more processors to perform the plurality of techniques of this disclosure. Each of video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, any of which may be integrated to form part of an integrated encoder / decoder (CODEC) combined within their respective devices. Devices including video encoder 20 and / or video decoder 30 may include integrated circuits, microprocessors, and / or wireless communication devices such as cellular telephones.

[0052] FIG. 2 is a block diagram illustrating one example of a video encoder 20 capable of implementing 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 remove spatial redundancy in the video within a given video frame or picture. Inter-coding relies on temporal prediction to reduce or remove temporal redundancy in the video within adjacent frames or pictures of a video sequence. The intra mode (I mode) may refer to any of several spatial-based coding modes. Inter modes such as unidirectional prediction (P mode, also known as single prediction) or bidirectional prediction (B mode, also known as dual prediction) may refer to any of several time-based coding modes.

[0053] As shown in FIG. 2, video encoder 20 receives the current video block in the video frame to be encoded. In the example of FIG. 2, video encoder 20 includes a mode selection unit 40, a reference frame memory 64, an adder 50 for summing, a conversion processing unit 52, a quantization unit 54, and an entropy encoding unit 56. Mode selection unit 40 similarly includes a motion compensation unit 44, a motion estimation unit 42, an intra prediction unit 46 (also known as intra prediction), and a partitioning unit 48. For the reconstruction of the video block, video encoder 20 also includes an inverse quantization unit 58, an inverse transform unit 60, and an adder 62 for summing. Further, it may include a deblocking filter (not shown in FIG. 2) for filtering the block boundary to remove block noise artifacts from the reconstructed video. Optionally, the deblocking filter will typically filter the output of adder 62 for summing. Also, in addition to the deblocking filter, additional filters (such as in-loop filters or post-loop filters) may be used. Such filters are not shown for simplicity, but may filter the output of adder 50 for summing (as an in-loop filter) if necessary.

[0054] During the encoding process, video encoder 20 receives the video frame or slice to be coded. It is possible to divide the frame or slice into a plurality of video blocks. Motion estimation unit 42 and motion compensation unit 44 perform inter-frame predictive coding of the received video block with respect to one or more blocks in one or more reference frames to provide a temporal prediction. Intra prediction unit 46 may alternatively perform intra-frame predictive coding of the received video block with respect to one or more adjacent blocks in the same frame or slice as the block to be coded to provide a spatial prediction. Video encoder 20 may execute a plurality of coding paths to select, for example, an appropriate coding mode for each block of the video data.

[0055] Furthermore, the partitioning unit 48 may partition a block of video data into sub-blocks based on an evaluation of a previous partitioning scheme in a previous coding path. For example, the partitioning unit 48 may first partition a frame or a slice into the largest coding units (LCUs), and then partition each of those multiple LCUs into sub-coding units (sub-CUs) based on a rate-distortion analysis (such as rate-distortion optimization). The mode selection unit 40 may further generate a quadtree data structure indicating the partitioning of the LCUs into sub-CUs. A leaf node CU of the quadtree may include one or more prediction units (PUs) and one or more transform units (TUs).

[0056] This disclosure uses the term "block" to refer to any of a CU, a PU, or a TU in the context of HEVC, or a similar data structure in the context of other standards (such as macroblocks and their sub-blocks in the context of H.264 / AVC). A CU includes a coding node, a PU, and a TU associated with the coding node. The size of a CU corresponds to the size of the coding node and is square-shaped. The size of a CU ranges from 8×8 pixels to the size of a tree block of 64×64 pixels or larger. Each CU may include one or more PUs and one or more TUs. The syntax data associated with a CU may describe, for example, the partitioning of the CU into one or more PUs. The partitioning mode may vary depending on whether the CU is coded in skip mode or direct mode, in intra prediction mode, or in inter prediction mode (also known as inter-frame prediction mode). A PU may be partitioned into a non-square shape. Also, the syntax data associated with a CU may describe, for example, the partitioning of the CU into one or more TUs according to a quadtree. A TU may be square or non-square (such as rectangular).

[0057] The mode selection unit 40 may select, for example, one of coding modes such as an intra-frame coding mode or an inter-frame coding mode based on the result of an error, and provide the adder 50 that sums to the resulting intra-frame coded block or inter-frame coded block to generate residual block data, and provide the residual block data to the adder 62 that sums to reconstruct the block coded for use as a reference frame. The mode selection unit 40 also provides syntax elements such as motion vectors, intra-frame mode indicators, segmentation information, and other such syntax information to the entropy coding unit 56.

[0058] 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 of generating motion vectors, and those motion vectors estimate the motion for video blocks. The motion vectors can indicate, for example, the displacement of the PU of a video block in the current video frame or picture with respect to a predicted block (or other coded unit) in a reference frame related to the current block (or other coded unit) being coded in the current frame. The predicted block is a block found to closely match the block to be coded with respect to pixel differences, and that predicted block may be determined by the sum of absolute differences (SAD), the sum of squared differences (SSD), or other difference metrics. In some of the plurality of examples, the video encoder 20 can calculate the values of the sub-pixel positions of the reference picture stored in the reference frame memory 64. For example, the video encoder 20 may interpolate the values of the 1 / 4 pixel position, 1 / 8 pixel position, or other fractional pixel positions of the reference picture. Accordingly, the motion estimation unit 42 may perform motion search regarding full pixel positions and fractional pixel positions and output motion vectors having fractional pixel accuracy.

[0059] The motion estimation unit 42 calculates the motion vectors for the PUs of the video blocks in the slice coded inter-frame by comparing the position of the predicted block of the reference picture with the position of the PU. The reference picture may be selected from the first reference picture list (List 0) or the second reference picture list (List 1), and each of the first reference picture list and the second reference picture list identifies one or more reference pictures stored in the reference frame memory 64. The motion estimation unit 42 sends the calculated motion vectors to the entropy Coding unit 56 and the motion compensation unit 44.

[0060] The motion compensation performed by motion compensation unit 44 may involve extracting or generating a prediction block based on the motion vectors determined by motion estimation unit 42. Although it is repetitive, in some of the plurality of examples, motion estimation unit 42 and motion compensation unit 44 may be functionally integrated. When receiving the motion vectors for the current video block's PU, motion compensation unit 44 can identify the position of the prediction block indicated by the motion vectors within one of those multiple reference picture lists. Adder 50 that takes the sum forms a residual video block by subtracting the pixel values of the prediction block from the pixel values of the current video block to be coded, as described below, and as a result, forms pixel difference values. Generally, motion estimation unit 42 performs motion estimation regarding the luminance component, and motion compensation unit 44 uses the motion vectors calculated based on the luminance component for both the chrominance component and the luminance component. Mode selection unit 40 can also generate syntax elements related to the video block and video slice for use by video decoder 30 when decoding the video blocks of the video slice.

[0061] Intra prediction unit 46 may perform intra prediction of the current block instead of the inter prediction performed by motion estimation unit 42 and motion compensation unit 44, as described above. In particular, intra prediction unit 46 may determine the intra prediction mode used to code the current block. In some of the plurality of examples, intra prediction unit 46 may code the current block using various intra prediction modes, for example, during an individual coding pass, and intra prediction unit 46 (or, in some of the plurality of examples, mode selection unit 40) can select an appropriate intra prediction mode for use from the modes being tested.

[0062] 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 having the best rate-distortion characteristics among those tested modes. Rate-distortion analysis generally determines not only the amount of distortion (or error) between the original unencoded block and the encoded block previously encoded to generate the encoded block, but also the bit rate (i.e., the number of bits) used to generate 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 that block.

[0063] In addition, the intra prediction unit 46 may be configured to code depth blocks of a depth map using a depth modeling mode (DMM). The mode selection unit 40 may, for example, use rate-distortion optimization (RDO) to determine whether an available DMM mode yields better coding results than the intra prediction mode and other DMM modes. Data for the texture image 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 perform inter prediction on the depth blocks of the depth map.

[0064] After selecting an intra prediction mode for a block (such as one of the conventional intra-frame prediction modes or one of the plurality of DMM modes), the intra prediction unit 46 may provide information indicating the selected intra prediction mode for that block to the entropy coding unit 56. The entropy coding unit 56 may encode the information indicating the selected intra prediction mode. The video encoder 20 may include configuration data in the transmitted bitstream, and the configuration data may include a plurality of modified intra prediction mode index tables (also referred to as codeword mapping tables) and a plurality of intra prediction mode index tables, definitions of the encoding of a plurality of 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 of those plurality of contexts.

[0065] The video encoder 20 forms a residual video block by subtracting prediction data from the mode selection unit 40 from the original video block to be coded. An adder 50 for taking the sum represents one or more components that perform this subtraction operation.

[0066] The transform processing unit 52 applies a transform such as a discrete cosine transform (DCT) or a conceptually similar transform to the residual block, resulting in a video block including residual transform coefficient values. The transform processing unit 52 may perform other transforms that are conceptually similar to the DCT. Also, a wavelet transform, integer transform, subband transform, or other type of transform may be used.

[0067] The conversion processing unit 52 applies a conversion to the residual block, as a result of which a block of residual conversion coefficients is generated. The conversion may convert the residual information from the pixel value domain to a conversion domain such as, for example, the frequency domain. The conversion processing unit 52 may send the resulting conversion coefficients to the quantization unit 54. The quantization unit 54 quantizes those conversion coefficients and further reduces the bit rate. The quantization process can reduce the bit depth associated with some or all of those multiple coefficients. By adjusting the quantization parameter, it is possible to modify the degree of quantization. In some of the plurality of 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.

[0068] Following quantization, the entropy coding unit 56 entropy-codes the quantized conversion 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), probability interval partitioning entropy (PIPE) coding, or other entropy coding techniques. In the case of context-based entropy coding, the context may be based on a plurality of adjacent blocks. Following the entropy coding by the entropy coding unit 56, the encoded bit stream may be transmitted to other devices (such as, for example, the video decoder 30), or may be archived for later transmission or retrieval.

[0069] The inverse quantization unit 58 and the inverse transform unit 60 each apply inverse quantization and inverse transform to reconstruct a residual block in a pixel region, for example, for later use as a reference block. The motion compensation unit 44 may calculate a reference block by adding the residual block to one of a plurality of 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-pixel values for use during motion estimation. The adder 62 that takes the sum 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 inter-frame coding of blocks in subsequent video frames.

[0070] FIG. 3 is a block diagram illustrating one example of a video decoder 30 capable of implementing video coding techniques. In the example of FIG. 3, the video decoder 30 includes an entropy decoding unit 70, a motion compensation unit 72, an intra-frame prediction unit 74, an inverse quantization unit 76, an inverse transform unit 78, a reference frame memory 82, and an adder 80 that takes the sum. In some of the plurality of examples, the video decoder 30 may perform a decoding path that is generally inverse to the encoding path described with respect to the video encoder 20 (FIG. 2). The motion compensation unit 72 may generate prediction data based on the motion vectors received from the entropy decoding unit 70, while the intra-frame prediction unit 74 may generate prediction data based on the intra-frame prediction mode indicator received from the entropy decoding unit 70.

[0071] During the decoding process, video decoder 30 receives an encoded video bitstream representing video blocks of an encoded video slice and associated syntax elements from video encoder 20. Entropy decoding unit 70 of video decoder 30 entropy decodes the bitstream to generate quantized coefficients, motion vectors or intra prediction mode indicators, and other syntax elements. Entropy decoding unit 70 transfers the motion vectors and other syntax elements to motion compensation unit 72. Video decoder 30 may receive syntax elements at the video slice level and / or at the video block level.

[0072] When the video slice is coded as an intra-coded (I) slice, intra prediction unit 74 may generate prediction data for the video blocks of the current video slice based on the intra prediction mode signaled and data from previously decoded blocks of the current frame or picture. When the video frame is coded as a slice coded inter-frame (e.g., B, P, or GPB, etc.), motion compensation unit 72 generates a prediction block for the video blocks of the current video slice based on the motion vectors and other syntax elements received from entropy decoding unit 70. Those prediction blocks may be generated from one of a plurality of reference pictures in one of a plurality of reference picture lists. Video decoder 30 may construct reference frame lists List0 and List1 using default construction techniques based on the reference pictures stored in reference frame memory 82.

[0073] The motion compensation unit 72 analyzes the motion vector and other syntax elements to determine prediction information for the video blocks of the current video slice, and uses the prediction information to generate a prediction block for the current video block to be decoded. For example, the motion compensation unit 72 uses some of the plurality of received syntax elements to determine the prediction mode (such as intra prediction or inter prediction, etc.) used to code the video blocks of the video slice, the inter prediction slice type (such as B slice, P slice, or GPB slice, etc.), the construction information for one or more of the plurality of reference picture lists for the slice, the motion vector for each inter-coded video block of the slice, the inter prediction state for each inter-coded video block of the slice, and other information for decoding the video blocks in the current video slice.

[0074] The motion compensation unit 72 may also perform interpolation based on the interpolation filter. The motion compensation unit 72 may use the interpolation filter used by the video encoder 20 during the encoding of the video block to calculate the interpolated values for the sub-pixel 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 syntax elements and use those interpolation filters to generate the prediction block.

[0075] The data for the texture image corresponding to the depth map may be stored in the reference frame memory 82. The motion compensation unit 72 may also be configured to perform inter prediction on the depth blocks of the depth map.

[0076] In one embodiment, 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 (such as a network administrator, etc.). Through the user interface 84, the user can manage or change settings in the video decoder 30. For example, the user can input or otherwise provide values for parameters (such as flags, etc.) to control the configuration and / or operation of the video decoder 30 according to the user's preferences. The user interface 84 may be, for example, a graphical user interface (GUI), and the graphical user interface enables the user to interact with the video decoder 30 through graphical icons, drop-down menus, check boxes, etc. In some cases, the user interface 84 may receive information from the user by means of a keyboard, a mouse, or other peripheral devices. In one embodiment, the user can access the user interface 84 by means of a smartphone, a tablet device, a personal computer located remotely from the video decoder 30, etc. As used herein, the user interface 84 may also be referred to as an external input or external means.

[0077] Taking the above into consideration, video compression techniques perform spatial (within picture) prediction and / or temporal (between pictures) prediction to reduce or remove redundancy inherent in a video sequence. For block-based video coding, a video slice (i.e., a video picture or a portion of a video picture) may be partitioned into a plurality of video blocks, which may also be referred to as tree blocks, coding tree blocks (CTBs), coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks within an intra-coded (I) slice of a picture are encoded using spatial prediction with respect to a plurality of reference samples within a plurality of adjacent blocks in the same picture. Video blocks within an inter-coded (P or B) slice of a picture may use spatial prediction with respect to a plurality of reference samples within a plurality of adjacent blocks in the same picture or temporal prediction with respect to a plurality of reference samples in another reference picture. A picture may be referred to as a frame, and a reference picture may be referred to as a reference frame.

[0078] Spatial or temporal prediction results in a predicted block for the block to be coded. Residual data represents the pixel difference between the original block to be coded and the predicted block. An inter-coded block is coded according to a motion vector, which indicates the block of reference samples forming the predicted block, and the residual data indicates the difference between the block being coded and the predicted block. An intra-coded block is coded according to an intra-coding mode and residual data. For further compression, the residual data may be transformed from a pixel domain to a transform domain, resulting in residual transform coefficients, which may then be quantized. The quantized transform coefficients are initially arranged in a two-dimensional array and may be scanned to generate a one-dimensional vector of transform coefficients, and entropy coding may be applied to achieve even more compression.

[0079] Image and video compression has continued to experience rapid growth, leading to various coding standards. Such video coding standards include 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, Advanced Video Coding (AVC) also known as 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 extension standards such as Scalable Video Coding (SVC), Multi-View Video Coding (MVC) and Multi-View Video Coding Plus Depth (MVC+D), and 3D AVC (3D-AVC). HEVC includes extension standards such as Scalable HEVC (SHVC), Multi-View HEVC (MV-HEVC), and 3D HEVC (3D-HEVC).

[0080] There is also a new video coding standard called Versatile Video Coding (VVC) being developed by the Joint Video Experts Team (JVET) of ITU-T and ISO / IEC. The VVC standard has several working drafts. In this specification, one of the working drafts (WD) of VVC is referred to, specifically, B. Bross, J. Chen and S. Liu, "Versatile Video Coding (Draft 5)", JVET-N1001-v3, 13th JVET Meeting, March 27, 2019 (VVC Draft 5).

[0081] The description of the multiple technologies disclosed in this specification is based on the Versatile Video Coding (VVC), a currently developing video coding standard by the Joint Video Experts Team (JVET) of ITU-T and ISO / IEC. On the other hand, these technologies are also applicable to other video codec standards.

[0082] Figure 4 represents the relationship between the leading picture 404 represented in decoding order 408 and the intra random access point (IRAP) picture 402 for the trailing picture 406, and the IRAP picture 402 for the leading picture 404 and the trailing picture 406 represented in presentation order 410, which is 400. In one embodiment, the IRAP picture 402 is referred to as a clean random access (CRA) picture or an instant decoder refresh (IDR) picture having a random access decodable (RADL) picture. In the case of HEVC, the IDR picture, the CRA picture, and the broken link access (BLA) picture are all considered to be the IRAP picture 402. For VVC, it has been agreed at the 12th JVET meeting in October 2018 that both the IDR picture and the CRA picture are included as the IRAP picture. In one embodiment, the broken link access (BLA) picture and the gradual decoder refresh (GDR) picture may also be considered to be the IRAP picture. The decoding process for the coded video sequence always starts from the IRAP.

[0083] A CRA picture is an IRAP picture in which each video coding layer (VCL) network abstraction layer (NAL) unit has a nal_unit_type equal to that of a CRA_NUT. A CRA picture does not reference any picture other than itself for inter-picture prediction in its decoding process, and may be the first picture in the bitstream presented in decoding order, or may appear later in the bitstream. A CRA picture may have associated RADL or random access skip leading (RASL) pictures. When a CRA picture has a NoOutputBeforeRecoveryFlag equal to 1, since the associated RASL pictures may contain references to pictures that do not exist in the bitstream, those associated RASL pictures may not be decodable, and thus are not output by the decoder.

[0084] As shown in FIG. 4, the leading pictures 404 (e.g., pictures 2 and 3) follow the IRAP picture 402 in decoding order 408, but precede the IRAP picture 402 in presentation order 410. The trailing picture 406 follows the IRAP picture 402 in both decoding order 408 and presentation order 410. Two leading pictures 404 and one trailing picture 406 are shown in FIG. 4, but those skilled in the art will understand that in actual applications, more leading pictures 404 and / or trailing pictures 406 or fewer leading pictures 404 and / or trailing pictures 406 may exist in decoding order 408 and presentation order 410.

[0085] The leading picture 404 in FIG. 4 is divided into two types: random access skip lossless (RASL) and RADL. When decoding starts from an IRAP picture 402 (such as picture 1), it is possible to appropriately decode RADL pictures (such as picture 3), but it is impossible to appropriately decode RASL pictures (such as picture 2). Therefore, RASL pictures are discarded. Considering the discrimination between RADL pictures and RASL pictures, the type of the leading picture 404 associated with the IRAP picture 402 needs to be identified as either RADL or RASL for efficient and proper coding. In the case of HEVC, when RASL and RADL pictures exist, it is suppressed that for the RASL picture and the RADL picture associated with the same IRAP picture 402, the RASL picture needs to be placed before the RADL picture in the presentation order 410.

[0086] The IRAP picture 402 provides the following two important functions / advantages. First, the presence of the IRAP picture 402 indicates that the decoding process can start from that picture. As long as the IRAP picture 402 exists at that position, this function enables the random access function where the decoding process starts not necessarily at the beginning of the bitstream but at that position within the bitstream. Second, the presence of the IRAP picture 402 updates the decoding process, so that the pictures coded starting from the IRAP picture 402 are coded without referring to the previous pictures, except for RASL pictures. Causing an IRAP picture 402 to exist in the bitstream will prevent errors that may occur during the decoding of the pictures coded before the IRAP picture 402 from propagating to the IRAP picture 402 and those pictures following the IRAP picture 402 in the decoding order 408.

[0087] The IRAP pictures 402 provide important functions, but on the other hand, those IRAP pictures 402 bring disadvantages to their compression efficiency. The presence of the IRAP pictures 402 causes a sharp increase in the bitrate. This disadvantage to the compression efficiency is due to two reasons. First, since the IRAP pictures 402 are pictures predicted intra-frame, the IRAP pictures 402 themselves will require relatively more bits to be presented when compared with other pictures that are predicted inter-frame (e.g., the leading pictures 404, the trailing pictures 406, etc.). Second, the presence of the IRAP pictures 402 interrupts the temporal prediction (this interruption is that in the decoding process, one of the multiple operations of the decoding process for this IRAP picture 402 is to remove the previous reference picture in the decoded picture buffer (DPB), and the decoder will update the decoding process), so the IRAP pictures 402 make the coding of the pictures following the IRAP pictures 402 in the decoding order 408 less efficient (i.e., require more bits for presentation) because those other pictures have fewer reference pictures for the inter-frame predictive coding of those other pictures.

[0088] Among the picture types considered as IRAP pictures 402, the IDR pictures in HEVC have different signaling and derivation when compared with other picture types. Some of the multiple differences are as follows.

[0089] For the signaling and derivation of the picture order count (POC) value of the IDR picture, the most significant bit (MSB) part of the POC is not derived from the previous key picture and is simply set to be equal to 0.

[0090] Regarding the signaling information required for the management of reference pictures, the slice header of an IDR picture does not contain the information that needs to be signaled to assist in the management of reference pictures. For other picture types (i.e., CRA pictures, trailing pictures, time-axis direction partial layer access (TSA) pictures, etc.), for the reference picture marking process (i.e., the process of determining the state of reference pictures in the decoded picture buffer (DPB) regardless of whether they are used for reference or not), information such as the reference picture set (RPS) described below or other forms of similar information (such as a reference picture list, etc.) is required. On the other hand, for IDR pictures, the presence of an IDR indicates that the decoding process only needs to mark all of the multiple reference pictures in the DPB as not being used for reference, so there is no need to signal such information.

[0091] In the case of HEVC and VVC, the IRAP picture 402 and the leading picture 404 may each be included in a single Network Abstraction Layer (NAL) unit. A set of those NAL units may be referred to as an access unit. The IRAP picture 402 and the leading picture 404 are given different NAL unit types, whereby it is possible for a system-level application to easily identify those different NAL unit types. For example, a video splicer can identify the IRAP picture 402 from non-IRAP pictures, in particular, without understanding the overly detailed content of the syntax elements in the coded bitstream, and identify the leading picture 404 from the trailing picture 406 by determining the RASL picture and the RADL picture, without the need to understand the coded picture type. The trailing picture 406 is related to the IRAP picture 402 and is the picture that follows the IRAP picture 402 in the presentation order 410. The picture may follow that particular IRAP picture 402 in the decoding order 408 and may be placed before any other IRAP picture 402 in the decoding order 408. For this reason, giving the IRAP picture 402 and the leading picture 404 their own NAL unit types is useful for such applications.

[0092] In the case of HEVC, the NAL unit types for IRAP pictures include the following NAL unit types.

[0093] BLA with leading pictures (BLA_W_LP): The NAL unit of a Broken Link Access (BLA) picture where one or more leading pictures may follow in the decoding order.

[0094] BLA with RADL (BLA_W_RADL): The NAL unit of a BLA picture where one or more RADL pictures may follow in the decoding order but no RASL pictures are present.

[0095] BLA without a leading picture (BLA_N_LP): A NAL unit of a BLA picture where no leading picture follows in decoding order.

[0096] IDR with RADL (IDR_W_RADL): A NAL unit of an IDR picture where one or more RADL pictures may follow in decoding order, but no RASL picture exists.

[0097] IDR without a leading picture (IDR_N_LP): A NAL unit of an IDR picture where no leading picture follows in decoding order.

[0098] CRA: A NAL unit of a clean random access (CRA) picture where a leading picture (i.e., either a RASL picture or a RADL picture, or both) may follow.

[0099] RADL: A NAL unit of a RADL picture.

[0100] RASL: A NAL unit of a RASL picture.

[0101] For VVC, the NAL unit types for IRAP picture 402 and leading picture 404 are the following NAL unit types.

[0102] IDR with RADL (IDR_W_RADL): A NAL unit of an IDR picture where one or more RADL pictures may follow in decoding order, but no RASL picture exists.

[0103] IDR without a leading picture (IDR_N_LP): A NAL unit of an IDR picture where no leading picture follows in decoding order.

[0104] CRA: NAL unit of a Clean Random Access (CRA) picture which may be followed by a Reading Picture (either a RASL picture or a RADL picture, or both).

[0105] RADL: NAL unit of a RADL picture.

[0106] RASL: NAL unit of a RASL picture.

[0107] Figure 5 illustrates a video bitstream 550 configured to implement a Gradual Decoding Refresh (GDR) technique 500. As used herein, video bitstream 550 may also be referred to as an encoded video bitstream, a bitstream, or a variation thereof. As shown in Figure 5, bitstream 550 includes a Sequence Parameter Set (SPS) 552, a Picture Parameter Set (PPS) 554, a slice header 556, and picture data 558.

[0108] The SPS 552 contains data common to all pictures in a picture sequence (SOP). In contrast, the PPS 554 contains data common to the entire picture. The slice header 556 contains information about the current slice, such as the slice type and which of the multiple reference pictures are used. The SPS 552 and PPS 554 may generally be referred to as parameter sets. The SPS 552, PPS 554, and slice header 556 are types of network abstraction layer (NAL) units. An NAL unit is a syntax structure that contains an indicator of the type of the subsequent data (such as, for example, 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, and a non-VCL NAL unit contains any relevant additional information such as parameter sets (important header data that can be applied to a large number of VCL NAL units) and supplementary enhancement information (timing information and other supplementary data that is not necessary to decode the values of samples in a video picture but can enhance the usefulness of the decoded video signal). Those skilled in the art will understand that the bitstream 550 may contain other parameters and information in actual applications.

[0109] The image data 558 in FIG. 5 includes data related to an image or video to be encoded or decoded. The image data 558 may simply be referred to as the payload or data carried within the bitstream 550. In one embodiment, the image data 558 includes a CVS 508 (or, CLVS), and the CVS 508 includes a GDR picture 502, one or more trailing pictures 504, and a recovery point picture 506. In one embodiment, the GDR picture 502 is referred to as a CVS start (CVSS) picture. The CVS 508 is a coded video sequence for any coded layer video sequence (CLVS) within the video bitstream 550. In particular, when the video bitstream 550 includes a single layer, the CVS and the CLVS are the same. The CVS and the CLVS are different only when the video bitstream 550 includes multiple layers. In one embodiment, since the trailing pictures 504 are placed before the recovery point picture 506 during the GDR period, those trailing pictures 504 may be considered a form of GDR picture.

[0110] In one embodiment, the GDR picture 502, the trailing pictures 504, and the recovery point picture 506 may define a GDR period within the CVS 508. In one embodiment, the decoding order starts from the GDR picture 502, continues to the trailing pictures 504, and then Recovery Point proceeds to the picture 506.

[0111] The CVS 508 is a series of pictures (or a portion thereof) starting from the GDR picture 502 and including all pictures (or a portion thereof) up to the next GDR picture or the end of the bitstream, but not including the next GDR picture. The GDR period is a series of pictures starting from the GDR picture 502 and including all pictures up to and including the recovery point picture 506. The decoding process of the CVS 508 always starts at the GDR picture 502.

[0112] As shown in FIG. 5, the GDR technology 500 or principle functions over a series of pictures starting from the GDR picture 502 and ending at the recovery point picture 506. The GDR picture 502 includes an updated / clean area 510 that contains blocks all coded using intra-frame prediction (i.e., blocks predicted within the frame), and an unupdated / dirty area 512 that contains blocks all coded using inter-frame prediction (i.e., blocks predicted between frames).

[0113] The end picture 504 immediately adjacent to the GDR picture 502 includes an updated / clean area 510 having a first part 510A coded using intra-frame prediction and a second part 510B coded using inter-frame prediction. The second part 510B is coded, for example, by referring to the updated / clean area 510 of a preceding picture during the GDR period of the CVS 508. As shown, the updated / clean area 510 of the end picture 504 expands as the coding process moves or progresses in a consistent direction (e.g., from left to right), and correspondingly, the unupdated / dirty area 512 shrinks. Finally, from that coding process, a recovery point picture 506 containing only the updated / clean area 510 is obtained. In particular, as further described below, the second part 510B of the updated / clean area 510 coded as an inter-frame prediction block may refer only to the updated / clean area 510 in the reference pictures.

[0114] As shown in FIG. 5, the GDR picture 502, the end picture 504, and the recovery point picture 506 in the CVS 508 are each contained within their own VCL NAL unit 530. The set of VCL NAL units 530 in the CVS 508 may be referred to as an access unit.

[0115] In one embodiment, a VCL NAL unit 530 that includes a GDR picture 502 in CVS 508 has a GDR NAL unit type (GDR_NUT). That is, in one embodiment, a VCL NAL unit 530 that includes a GDR picture 502 in CVS 508 has its own unique NAL unit type with respect to the trailing picture 504 and recovery point picture 506. In one embodiment, GDR_NUT enables the bitstream 550 to start from the GDR picture 502 instead of the bitstream 550 having to start from an IRAP picture. Designating the VCL NAL unit 530 of the GDR picture 502 as GDR_NUT makes it possible, for example, to indicate to the decoder that an initial VCL NAL unit 530 in CVS 508 includes the GDR picture 502. In one embodiment, the GDR picture 502 is an initial picture in CVS 508. In one embodiment, the GDR picture 502 is an initial picture during a GDR period.

[0116] FIG. 6 is a schematic diagram illustrating an undesirable motion search 600 when using encoder constraints to support GDR. As shown, the motion search 600 shows a current picture 602 and a reference picture 604. The current picture 602 and the reference picture 604 each include an updated region 606 coded using intra-frame prediction, an updated region 608 coded using inter-frame prediction, and a non-updated region 608. The updated region 604, the updated region 606, and the non-updated region 608 are similar to the first part 510A of the updated / clean region 510, the second part 510B of the updated / clean region 510, and the non-updated / dirty region 512 of FIG. 5.

[0117] During the motion search process, the encoder is inhibited or prevented from selecting any of the motion vectors 610 that result in some of the plurality of samples of the reference block 612 located outside the updated region 606. This occurs even when the reference block 612 provides the best rate-distortion cost criterion when predicting the current block 614 in the current picture 602. In this way, FIG. 6 illustrates the reason for the non-optimality in the motion search 600 when using encoder constraints to support GDR.

[0118] FIG. 7 illustrates a video bitstream 750 configured to implement a clean random access (CRA) technique 700. As used herein, the video bitstream 750 may also be referred to as an encoded video bitstream, a bitstream, or a variation thereof. As shown in FIG. 7, the bitstream 750 includes a sequence parameter set (SPS) 752, a picture parameter set (PPS) 754, a slice header 756, and picture data 758. The bitstream 750, SPS 752, PPS 754, and slice header 756 in FIG. 7 are similar to the bitstream 550, SPS 552, PPS 554, and slice header 556 in FIG. 5. Therefore, for the sake of brevity, the description of these elements will not be repeated.

[0119] The picture data 758 in FIG. 7 includes data related to an image or video to be encoded or decoded. The picture data 758 may simply be referred to as the payload or data carried in the bitstream 750. In one embodiment, the picture data 758 includes a CRA picture 702, one or more trailing pictures 704, and Sequence Picture a CVS 708 (or, CLVS) including the end of 706. In one embodiment, the CRA picture 702 is referred to as a CVSS picture. The decoding process of the CVS 708 always starts from the CRA picture 702.

[0120] As shown in FIG. 7, the ends of the CRA picture 702, the last picture 704, and the sequence picture 706 in the CVS 708 are each included in their own VCL NAL unit 730. The set of VCL NAL units 730 in the CVS 708 may be referred to as an access unit.

[0121] In the latest draft of the VVC specification, the output of the picture before the IRAP picture is defined as follows. The previous picture (e.g., a picture that has been decoded previously) for the IRAP picture is (1) decoded at a point in time earlier than that IRAP picture, (2) shown for output, (3) present in the decoded picture buffer (DPB) at the start of decoding of that IRAP picture, and (4) refers to those pictures that are not output at the start of decoding of that IRAP picture. As used herein, the previous picture may also be referred to as a previously decoded picture.

[0122] The slice header syntax includes the syntax element no_output_of_prior_pics_flag for IDR pictures and CRA pictures. Its semantics are as follows.

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

[0124] Section C.3.2 of VVC draft 5 (Deletion of pictures from the DPB before decoding of the current picture) includes the following description.

[0125] - When the current picture is an IRAP picture with a NoIncorrectPicOutputFlag equal to 1 and not equal to 0, apply the following ordered steps.

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

[0127] - When the current picture is a CRA picture, NoOutputOfPriorPicsFlag is set to be equal to 1 (regardless of the value of no_output_of_prior_pics_flag).

[0128] - Otherwise, if the values of 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 are different from the values of 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 previous picture, respectively, then NoOutputOfPriorPicsFlag may be set to 1 in the decoder under test (but it is not necessary to set it to 1), regardless of the value of no_output_of_prior_pics_flag.

[0129] Note - Under these conditions, it is desirable to set NoOutputOfPriorPicsFlag to be equal to no_output_of_prior_pics_flag, but in this case, the decoder under test is permitted to set NoOutputOfPriorPicsFlag to 1.

[0130] - Otherwise, NoOutputOfPriorPicsFlag is set to be equal to no_output_of_prior_pics_flag.

[0131] 2. The value of NoOutputOfPriorPicsFlag derived for the decoder under test is applied to the Hypothetical Reference Decoder (HRD), such that when the value of NoOutputOfPriorPicsFlag is equal to 1, all of the picture memory buffers in the DPB are emptied without using the output of the pictures they contain, and the DPB fullness is set to be equal to 0.

[0132] Section C.5.2.2 (Output and deletion of pictures from the DPB) of VVC Draft 5 includes the following description.

[0133] - When the current picture is an IRAP picture with NoIncorrectPicOutputFlag equal to 1 (not picture 0), the following ordered steps are applied.

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

[0135] - When the current picture is a CRA picture, NoOutputOfPriorPicsFlag is set to be equal to 1 (regardless of the value of no_output_of_prior_pics_flag).

[0136] - Otherwise, if the values of 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 are different from the values of 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 previous picture respectively, NoOutputOfPriorPicsFlag may be set to 1 by the decoder under test (but it is not necessary to set it to 1), regardless of the value of no_output_of_prior_pics_flag.

[0137] Note - Under these conditions, it is desirable to set NoOutputOfPriorPicsFlag to be equal to no_output_of_prior_pics_flag, but in this case, the decoder under test is permitted to set NoOutputOfPriorPicsFlag to 1.

[0138] - Otherwise, NoOutputOfPriorPicsFlag is set to be equal to no_output_of_prior_pics_flag.

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

[0140] - When NoOutputOfPriorPicsFlag is equal to 1, all of the picture memory buffers in the DPB are emptied without using the output of the pictures they contain, and the DPB fullness is set to be equal to 0.

[0141] - Otherwise (when NoOutputOfPriorPicsFlag is equal to 0), all of the picture memory buffers that contain pictures marked as "not needed for output" and "not used for reference" are emptied (without using the output), and all of the non-empty picture memory 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 be equal to 0.

[0142] Multiple problems of the existing design have been described.

[0143] In the latest draft of the VVC specification, in the case of a CRA picture where NoIncorrectPicOutputFlag is equal to 1 (i.e., a CRA picture that starts a new CVS), the value of NoOutputOfPriorPicsFlag is set to be 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. This means that the pictures before each CRA picture that starts a CVS are not output. On the other hand, similar to the case of IDR pictures, the output / display of the previous pictures can provide a more continuous playback, and thus, as long as the DPB does not overflow when decoding the pictures that start a new CVS and the subsequent pictures in decoding order, it is possible to provide a better user experience.

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

[0145] This disclosure also applies to other types of pictures that start a new CVS, such as progressive random access (GRA) pictures currently specified in the draft of the latest VVC specification, for example. In one embodiment, the GRA picture may be referred to as, or be synonymous with, a GDR picture.

[0146] As an 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 that is in the buffer of decoded pictures and was decoded earlier than the CRA picture is output when the CRA picture starts a newly coded video sequence. That is, the previous picture is output when the value of the flag (such as when its value is equal to 0) indicates that the previous picture is to be output. In one embodiment, the flag is specified as the no_output_of_prior_pics_flag.

[0147] As another example, when decoding a video bitstream, a flag corresponding to a gradual random access (GRA) picture is signaled in the bitstream. The flag specifies whether a decoded picture that is in the buffer of decoded pictures and has been decoded earlier than the GRA picture is output when the GRA picture starts a newly coded video sequence. That is, when the value of the flag indicates (such as when the value is equal to 0) that the previous picture is to be output, the previous picture is output. In one embodiment, the flag is specified as no_output_of_prior_pics_flag.

[0148] Techniques for output of previous pictures (such as previously decoded pictures) in a buffer of decoded pictures (DPB) when encountering in decoding order random access point pictures (such as clean random access (CRA) pictures, gradual random access (GRA) pictures, or gradual decoding refresh (GDR) pictures, CVSS pictures, etc.) other than instantaneous decoder refresh (IDR) pictures are disclosed herein. Emptying the previously decoded pictures from the DPB when reaching a random access point picture prevents the DPB from causing an overflow and promotes more continuous playback. Thus, the coder / decoder (also known as a "codec") in video coding is improved compared to current codecs. As a practical matter, the improved video coding process provides a better user experience to the user when the video is transmitted, received, and / or viewed.

[0149] FIG. 8 is one embodiment of a method 800 for decoding a coded video bitstream implemented by a video decoder (such as, for example, video decoder 30). The method 800 may be performed after receiving the decoded bitstream directly or indirectly from a video encoder (such as, for example, video encoder 20). The method 800 improves the decoding process by emptying the DPB when a random access point picture is encountered and before decoding the current picture. The method 800 prevents the DPB from causing an overflow and promotes more continuous playback. Thus, as a practical matter, codec performance is improved, leading to a better user experience.

[0150] In block 802, the video decoder receives a coded video bitstream (such as, for example, bitstream 750). The coded video bitstream includes a first flag having a first value and a clean random access (CRA) picture. In one embodiment, the CRA picture is not the first picture of the coded video bitstream. In one embodiment, the first flag is designated as no_output_of_prior_pics_flag.

[0151] In block 804, the video decoder sets a second value of a second flag to be equal to the first value of the first flag. In one embodiment, the second flag is designated as NoOutputOfPriorPicsFlag. In one embodiment, the second flag exists internally to the decoder.

[0152] In block 806, the video decoder empties all previously decoded pictures from the decoded picture buffer (DPB) based on a second flag having a second value. In one embodiment, after decoding a CRA picture, the previously decoded pictures are emptied from the DPB. That is, the video decoder removes the previously decoded pictures from the picture storage buffer in the DPB. In one embodiment, when the previously decoded pictures are removed from the DPB, those previously decoded pictures are not output or displayed. In one embodiment, when the first flag is set to the first value, the DPB fullness parameter is set to 0. The DPB fullness parameter indicates how many pictures are stored in the DPB. Setting the DPB fullness parameter to 0 indicates that the DPB is empty.

[0153] In block 808, the video decoder decodes the current picture after the DPB has been emptied. In one embodiment, the current picture is a picture from the same CVS as the CRA picture and, in decoding order, the current picture is obtained or encountered after the CRA. In one embodiment, an image generated based on the current picture is displayed for a user of an electronic device (such as a smartphone, tablet, laptop, personal computer, etc.).

[0154] FIG. 9 is one embodiment of a method 900 for encoding a video bit stream implemented by a video encoder (such as, for example, video encoder 20). The method 900 may be performed when a picture (such as, for example, from a video) is encoded into a video bit stream and then transmitted towards a video decoder (such as, for example, video decoder 30). The method 900 improves the encoding process by instructing the video decoder to empty the DPB when a random access point picture is encountered, before decoding the current picture. The method 900 prevents the DPB from causing an overflow and promotes more continuous playback. Thus, as a practical matter, codec performance is improved, leading to a better user experience.

[0155] In block 902, the video encoder determines a random access point for the video sequence. In block 904, the video encoder encodes a clean random access (CRA) picture to be the video sequence at the random access point. In one embodiment, the CRA picture is not the first picture of the video bit stream.

[0156] In block 906, the video encoder sets a flag to a first value and 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 decoding the CRA picture. In one embodiment, the flag is specified as the no_output_of_prior_pics_flag. In one embodiment, the video encoder instructs the video decoder to set the DPB fullness parameter to 0 when the flag is set to the first value. In one embodiment, the first value of the flag is 1.

[0157] In block 908, the video encoder generates a video bitstream including a video sequence having a CRA picture at a random access point and a flag. In block 910, the video encoder stores the video bitstream for transmission to a video decoder.

[0158] The following syntax and semantics may be used to implement the various embodiments disclosed herein. The following description is related to the base text, which is a draft of the latest specification of VVC. In other words, only deltas are described, while the text in the base text not mentioned below is applied as is. The text added compared to the base text is shown in bold, and the deleted text is shown in italics.

[0159] [Table 1]

[0160] [Number]

[0161] FIG. 10 is a schematic diagram of a video coding device 1000 (such as, for example, video encoder 20 or video encoder 30) according to one embodiment of this disclosure. The video coding device 1000 is suitable for implementing a plurality of disclosed embodiments as 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 data, a transmitter unit (Tx) 1040 and an outlet port 1050 for transmitting data, and a memory 1060 for storing data. The video coding device 1000 may also include optoelectronic (OE) components and electro-optic (EO) components coupled to the inlet port 1010, the receiver unit 1020, the transmitter unit 1040, and the outlet port 1050 for an outlet or inlet of an optical signal or an electrical signal.

[0162] The processor 1030 is implemented by hardware and software. The processor 1030 may be implemented as one or more CPU chips, cores (such as, for example, a multi-core processor), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and a digital signal processor (DSP). The processor 1030 communicates with the inlet port 1010, the receiver unit 1020, the transmitter unit 1040, the outlet port 1050, and the memory 1060. The processor 1030 includes a coding module 1070. The coding module 1070 implements a plurality of disclosed embodiments described above. For example, the coding module 1070 implements, processes, prepares, or provides various codec functions. Thus, including the coding module 1070 results in a substantial improvement in the functionality of the video coding device 1000 and results in a conversion of the video coding device 1000 to different states. Alternatively, the coding module 1070 is implemented as instructions stored in the memory 1060 and executed by the processor 1030.

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

[0164] 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 such programs when selecting a program for execution, and may store instructions and data read out during the execution of the program. Memory 1060 may be, for example, volatile and / or non-volatile, and may be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and / or static random access memory (SRAM).

[0165] FIG. 11 is a schematic diagram of one embodiment of means 1100 for coding. In one embodiment, means 1100 for coding is implemented by a video coding device 1102 (such as video encoder 20 or video decoder 30, for example). Video coding device 1102 includes receiving means 1101. Receiving means 1101 is configured to receive a picture to be encoded or a bitstream to be decoded. Video coding device 1102 includes transmitting means 1107 coupled to receiving means 1101. Transmitting means 1107 is configured to transmit a bitstream to a decoder or an image that has been decoded to a display means (such as one of a plurality of I / O devices 1080, for example).

[0166] 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 the instructions stored in the storage means 1103 to execute the methods disclosed herein.

[0167] Also, it should be understood that the steps of the exemplary methods described herein need not necessarily be performed in the order described, and that the order of such method steps is to be regarded as exemplary only. Similarly, additional steps may be included in such methods, and a step may be omitted or combined in a manner consistent with various embodiments of this disclosure.

[0168] Although several of the embodiments are provided by 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 considered to be exemplary and not restrictive, and the intention is not to be limited to the details given herein. For example, various elements or components may be combined or integrated to form other systems, or several features may be omitted or not implemented.

[0169] In addition, without departing from the scope of this disclosure, the techniques, systems, subsystems, and methods separately or individually described and illustrated in various embodiments may be combined or integrated with other systems, modules, techniques, or methods. Other items that are coupled or directly coupled or communicating with each other may be indirectly coupled or communicating by some interfaces, devices, or intermediate components, electrically, mechanically, or otherwise. Other examples of changes, substitutions, and modifications are ascertainable by those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims

1. A method of decoding implemented by a video decoder, comprising: receiving, by the video decoder, a coded video bitstream, the coded video bitstream including a first flag having a first value and a clean random access (CRA) picture; setting, by the video decoder, a second value of a second flag to be equal to the first value of the first flag; emptying, by the video decoder, any previously decoded pictures from a decoded picture buffer (DPB) based on the second flag having the second value; decoding, by the video decoder, a current picture after the DPB is emptied; A method.

2. The method according to claim 1, wherein the CRA picture is not the first picture of the coded video bitstream.

3. The method according to any one of claims 1 to 2, further comprising setting a DPB fullness parameter to 0 when the first flag is set to the first value.

4. The method according to any one of claims 1 to 3, wherein the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag.

5. The method according to any one of claims 1 to 4, wherein the DPB is emptied after the CRA picture is decoded.

6. The method according to any one of claims 1 to 5, further comprising displaying an image generated based on the current picture.

7. A method of encoding implemented by a video encoder, comprising: determining, by the video encoder, a random access point for a video sequence; encoding, by the video encoder, a clean random access (CRA) picture to form the video sequence at the random access point; A step of instructing a video decoder by the video encoder to set a flag to a first value and empty all previously decoded pictures from a buffer (DPB) of decoded pictures; A step of generating, by the video encoder, a video bitstream including the video sequence having the CRA picture at the random access point and the flag; A step of storing, by the video encoder, the video bitstream for transmission to the video decoder, including; Method.

8. The method according to claim 7, wherein the CRA picture is not the first picture of the video bitstream, and the video decoder is instructed to empty the DPB after the CRA picture is decoded.

9. The method according to any one of claims 7 to 8, further including a step of instructing the video decoder to set a DPB fullness parameter to 0 when the flag is set to the first value.

10. The method according to any one of claims 7 to 9, wherein the flag is specified as no_output_of_prior_pics_flag.

11. The method according to any one of claims 7 to 10, wherein the first value of the flag is 1.

12. A decoding device, A receiver configured to receive a coded video bitstream, A memory coupled to the receiver, the memory storing instructions, the memory, A processor coupled to the memory, the processor executing the instructions such that the decoding device, Receives the coded video bitstream, the coded video bitstream including a first flag having a first value and a clean random access (CRA) picture, Sets a second value of a second flag to be equal to the first value of the first flag, Based on the second flag having the second value, empties all previously decoded pictures from a buffer (DPB) of decoded pictures, and, After the DPB is emptied, decodes a current picture, Configured to be such.

13. The decoding device according to claim 12, wherein the CRA picture is not the first picture of the coded video bitstream.

14. The decoding device according to any one of claims 12 to 13, wherein the first flag is specified as no_output_of_prior_pics_flag and the second flag is specified as NoOutputOfPriorPicsFlag.

15. The decoding device according to any one of claims 12 to 14, further comprising a display configured to display an image generated based on the current picture.

16. An encoding device, a memory for storing instructions, a processor coupled to the memory, the processor implementing the instructions such that the encoding device determines a random access point for a video sequence, encodes a clean random access (CRA) picture to form the video sequence at the random access point, sets a flag to a first value to instruct a video decoder to empty any previously decoded pictures from a buffer (DPB) of decoded pictures, and generates the video bitstream including the video sequence having the CRA picture at the random access point and the flag. a processor configured to cause; a transmitter coupled to the processor, the transmitter configured to transmit the video bitstream to a video decoder, An encoding device.

17. The encoding device according to claim 16, wherein the CRA picture is not the first picture of the video bitstream.

18. The encoding device according to any one of claims 16 to 17, wherein the flag is specified as no_output_of_prior_pics_flag.

19. The encoding device according to any one of claims 16 to 18, wherein the memory stores the bitstream before the transmitter transmits the bitstream to the video decoder.

20. An encoding apparatus A receiver configured to receive a picture for symbolization or to receive a bitstream for decoding; A transmitter coupled to the receiver, the transmitter being configured to transmit the bitstream to a decoder or to transmit a 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; A processor coupled to the memory, the processor being configured to execute the instructions stored in the memory to perform the method according to any one of claims 1 to 6 and any one of claims 7 to 11; including a processor. Coding device.

21. The coding device according to claim 20, further comprising a display configured to display an image.

22. A system, An encoder; A decoder communicating with the encoder, wherein the encoder or the decoder includes a decoding device, an encoding device, or a coding device according to any one of claims 12 to 21. System.

23. Means for coding, Receiving means configured to receive a picture for encoding or to receive a bitstream for decoding; Transmitting means coupled to the receiving means, the transmitting means being configured to transmit the bitstream to decoding means or to transmit a decoded image to display means; Storage means coupled to at least one of the receiving means or the transmitting means, the storage means being configured to store instructions; Processing means coupled to the storage means, the processing means being configured to execute the instructions stored in the storage means to perform the method according to any one of claims 1 to 6 and any one of claims 7 to 11; Means.

Images