Cross Random Access Point Sample Group

Abstract

A mechanism for processing video data is disclosed. Cross Random access point Referencing (CRR) samples are signaled. An indication indicates whether a picture that follows a Dependent Random Access Point (DRAP) picture in decoding order and precedes the DRAP picture in output order is allowed to refer to a reference picture that precedes the DRAP picture in decoding order for inter prediction. A conversion is performed between visual media data and a visual media file based on the CRR sample group.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of International Application No. PCT / CN2020 / 139893, filed December 28, 2020 by Ye-Kui Wang et al. and entitled "Signalling Of Cross Random Access Point Referencing In Video Bitstreams And Media Files," which is incorporated herein by reference.

[0002] This patent document relates to the creation, storage and consumption of digital audiovisual media information in file format. [Background technology]

[0003] Digital video accounts for the largest bandwidth usage on the Internet and other digital communications networks, and the bandwidth demands for digital video use will continue to grow as the number of connected user devices capable of receiving and displaying video increases. Summary of the Invention

[0004] A first aspect relates to a method for processing video data, including determining a description of Cross Random access point Referencing (CRR) samples in ISO (International Organization for Standardization) Base Media File Format (ISOBMFF) visual media data, and performing a conversion between the visual media data and a visual media data file based on a group of the CRR samples.

[0005] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample is included in a group of CRR samples.

[0006] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample is included in a group of Dependent Random Access Point (DRAP) samples.

[0007] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample is included in a group of Type 2 DRAP samples.

[0008] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample is included in a group of Enhanced Dependent Random Access Point (EDRAP) samples.

[0009] Optionally, in any of the above aspects, another implementation of the aspect provides setting the indication to a first value if a picture that follows the DRAP picture in decoding order and precedes the DRAP picture in output order is allowed to reference a reference picture that is located before the DRAP picture in decoding order for inter prediction.

[0010] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample is included in a CompactSampleToGroupBox.

[0011] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample is included in a group_type_parameter field.

[0012] Optionally, in any of the above aspects, another implementation of the aspect provides that the CRR sample is indicated as a Type 2 DRAP sample.

[0013] Optionally, in any of the above aspects, another implementation of this aspect provides that the CRR sample is denoted as an Enhanced Dependent Random Access Point (EDRAP) sample.

[0014] Optionally, in any of the preceding aspects, another implementation of this aspect provides that each sample comprises a picture.

[0015] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample includes one or more identifiers for identifying the sample as belonging to the sample group.

[0016] Optionally, in any of the above aspects, another implementation of the aspect provides that the description of the CRR sample includes an identifier of a reference picture for the CRR sample.

[0017] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample includes a number of samples that need to be referenced to decode the current sample.

[0018] Optionally, in any of the above aspects, another implementation of this aspect provides that the description of the CRR sample is included in a sample entry of the sample group.

[0019] Optionally, in any of the above aspects, another implementation of this aspect provides that if the current sample references only the closest preceding initial sample, one or more CRR samples that precede the current sample in decoding order, or a combination thereof, then the current sample is one of the CRR samples.

[0020] Optionally, in any of the above aspects, another implementation of this aspect provides that the current sample is one of the CRR samples if the current sample and all samples following the current sample in the decoding order and output order can be correctly decoded when decoding starts at the current sample.

[0021] Optionally, in any of the above aspects, another implementation of this aspect provides that the current sample and all samples following the current sample are correctly decoded after the closest preceding initial sample, one or more samples that precede the current sample in the decoding order, or a combination thereof, are decoded.

[0022] Optionally, in any of the preceding aspects, another implementation of this aspect provides that the converting includes generating a visual media data file according to the visual media data.

[0023] Optionally, in any of the preceding aspects, another implementation of this aspect provides that the converting includes parsing the visual media data file to obtain the visual media data.

[0024] A second aspect is an apparatus for processing video data comprising a processor and a non-transitory memory having instructions stored thereon that, when executed by the processor, cause the processor to perform a method of any of the previous aspects.

[0025] A third aspect is a non-transitory computer-readable medium comprising a computer program product for use in a video coding device, the computer program product comprising computer-executable instructions stored on the non-transitory computer-readable medium that, when executed by a processor, causes the video coding device to perform a method of any of the preceding aspects.

[0026] For clarity, any one of the above-described embodiments may be combined with any other one of the above-described embodiments to create a new embodiment that is within the scope of the present disclosure.

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

[0028] For a more complete understanding of this disclosure, reference should be made to the following brief description taken in conjunction with the accompanying drawings and detailed description, where like reference numbers represent like parts. [Brief description of the drawings]

[0029] [Figure 1] A schematic diagram showing an exemplary mechanism for random access when decoding a bitstream using IRAP pictures. [Diagram 2] FIG. 1 is a schematic diagram illustrating an exemplary mechanism for random access when decoding a bitstream using DRAP pictures. [Diagram 3] A schematic diagram showing an exemplary mechanism for random access when decoding a bitstream using CRR pictures. [Figure 4] 1 is a schematic diagram of an example mechanism for signaling an external bitstream to support CRR-based random access. [Diagram 5] FIG. 13 is a schematic diagram illustrating potential decoding errors when a picture follows a DRAP and / or CRR picture in decoding order and precedes the DRAP and / or CRR picture in output order. [Figure 6] FIG. 1 is a schematic diagram of a media file stored in ISOBMFF (ISO (International Organization for Standardization) Base Media File Format). [Figure 7] FIG. 2 is a block diagram of a bitstream containing encoded visual media data. [Figure 8] FIG. 1 is a block diagram illustrating an example of a video processing system. [Figure 9] FIG. 1 is a block diagram illustrating an example of a video processing device. [Figure 10] 1 is a flow chart illustrating an example of a method for video processing. [Figure 11] 1 is a block diagram illustrating an example of a video coding system. [Figure 12] FIG. 2 is a block diagram illustrating an example of an encoder. [Figure 13] FIG. 2 is a block diagram illustrating an example of a decoder. [Figure 14] FIG. 2 is a circuit diagram of an example of an encoder. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] While the following provides an example implementation for one or more embodiments, it should be understood at the outset that the disclosed systems and / or methods may be implemented using any number of technologies, whether currently known or yet to be developed. The present disclosure should in no way be limited to the example implementations, drawings, and technologies illustrated below, including the example designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims, along with their full scope of equivalents.

[0031] The term VVC (Versatile Video Coding), also known as H.266, is used in certain descriptions for ease of understanding only and is not used to limit the scope of the disclosed technology. As such, the technology described herein is applicable to other video codec protocols and designs. In this document, editorial changes with respect to the VVC specification or the ISO (International Organization for Standardization) Base Media File Format (ISOBMFF) file format specification are indicated with bold italics to indicate strikethroughs and underlines to indicate additions to the text.

[0032] This patent document relates to video coding, video file formats, video signaling, and video applications. Specifically, this document relates to enhanced signaling of Cross Random Access Point (RAP) referencing in video coding based on Supplemental Enhancement Information (SEI) messages, and signaling of Cross RAP Referencing (CRR) in media files. The disclosed examples may be applied, individually or in various combinations, to any video coding standard or non-standard video codec, e.g., VVC, and any media file format, e.g., ISOBMFF.

[0033] This disclosure includes the following abbreviations. ACT (Adaptive Color Transform), ALF (Adaptive Loop Filter), AMVR (Adaptive Motion Vector Resolution), APS (Adaptation Parameter Set), AU (Access Unit), AUD (Access Unit Delimiter), AVC (Advanced Video Coding (Rec. ITU-T H.264|ISO / IEC 14496-10)), B (Bi-predictive), BCW (Bi-prediction with CU-level Weights), BDOF (Bi-Directional Optical Flow), BDPCM (Block-based Delta Pulse Code Modulation), BP (Buffering Period), CABAC (Context-based Adaptive Binary Arithmetic Coding), CB (Coding Block), CBR (Constant Bit Rate), CCALF (Cross-Component Adaptive Loop Filter), CLVS (Coded Layer Video Sequence), CLVSS (Coded Layer Video Sequence Start), CPB (Coded Picture Buffer), CRA (Clean Random Access), CRC (Cyclic Redundancy Check), CRR (Cross RAP Referencing), CTB (Coding Tree Block), CTU (Coding Tree Unit), CU (Coding Unit), CVS (Coded Video Sequence), CVSS (Coded Video Sequence Start), DCI (Decoding Capability Information), DPB (Decoded Picture Buffer), DRAP (Dependent Random Access Point), DU (Decoding Unit), DUI (Decoding UnitInformation), EG (Exponential-Golomb), EGk (k-th order Exponential-Golomb), EOB (End Of Bitstream), EOS (End Of Sequence), FD (Filler Data), FIFO (First-In, First-Out), FL (Fixed-Length), GBR (Green, Blue, Red), GCI (General Constraints Information), GDR (Gradual Decoding Refresh), GPM (Geometric Partitioning Mode), HEVC (High Efficiency Video Coding; alias Rec.ITU-T H.265|ISO / IEC 23008-2), HRD (Hypothetical Reference Decoder), HSS (Hypothetical Stream Scheduler), I (Intra), IBC (Intra Block Copy), IDR (Instantaneous Decoding Refresh), ILRP (Inter Layer Reference Picture), IRAP (Intra Random Access Point), LFNST (Low Frequency Non-Separable Transform), LPS (Least Probable Symbol), LSB (Least Significant Bit), LTRP (Long-Term Reference Picture), LMCS (Luma Mapping with Chroma Scaling), MIP (Matrix-based Intra Prediction), MPS (Most Probable Symbol), MSB (Most Significant Bit), MTS (Multiple Transform Selection), MVP (Motion Vector Prediction), NAL (Network Abstraction Layer), OLS (Output Layer Set), OP (Operation Point), OPI (Operating PointInformation), P(Predictive), PH(Picture Header), POC(Picture Order Count), PPS(Picture Parameter Set), PROF(Prediction Refinement with Optical Flow), PT(Picture Timing), PU(Picture Unit), QP(Quantization Parameter), RADL(Random Access Decodable Leading Picture), RAP(Random Access Point), RASL(Random Access Skipped Leading) Picture), RBSP (Raw Byte Sequence Payload), RGB (Red, Green, Blue), RPL (Reference Picture List), SAO (Sample Adaptive Offset), SAR (Sample Aspect Ratio), SEI (Supplemental Enhancement Information), SH (Slice Header), SLI (Subpicture Level Information), SODB (String Of Data Bits), SPS (Sequence Parameter) Set), STRP (Short-Term Reference Picture), STSA (Step-wise Temporal Sublayer) Access), TR (Truncated Rice), TU (Transform Unit), VBR (Variable Bit Rate), VCL (Video Coding Layer), VPS (Video Parameter Set), VSEI (Versatile Supplemental Enhancement Information, also known as Rec. ITU-T H.274 | ISO / IEC 23002-7), VUI (Video Usability Information), and VVC (Versatile Video Coding, also known as Rec. ITU-T H.266 | ISO / IEC 23090-3).

[0034] Video coding standards have evolved primarily through the development of ITU-T and ISO / IEC standards. ITU-T created H.261 and H.263, while ISO / IEC created MPEG-1 and MPEG-4 Visual, and the two organizations jointly created H.262 / MPEG-2Video, H.264 / MPEG-4AVC (Advanced Video Coding), and H.265 / HEVC standards. Since H.262, video coding standards have been based on hybrid video coding structures, where transform coding is also used in addition to temporal prediction. To explore further video coding techniques beyond HEVC, the Video Coding Experts Group (VCEG) and MPEG jointly established the Joint Video Exploration Team (JVET). Many methods have been adopted by JVET and incorporated into reference software called Joint Exploration Mode (JEM). JVET was later renamed to Joint Video Experts Team (JVET) when the Versatile Video Coding (VVC) project was officially launched. VVC is a coding standard that aims to achieve a 50% bitrate reduction compared to HEVC. VVC has been finalized by JVET.

[0035] The VVC and VSEI standards are designed for use in the broadest possible range of applications, including television broadcast, video conferencing, playback from storage media, adaptive bitrate streaming, video region extraction, composition and merging of content from multiple coded video bitstreams, multi-view video, scalable layered coding, and viewport-adaptive 360° immersive media applications.

[0036] The Essential Video Coding (EVC) standard (ISO / IEC 23094-1) is another video coding standard developed by MPEG.

[0037] File format standards are described below. Media streaming applications are generally based on Internet Protocol (IP), Transmission Control Protocol (TCP), and Hypertext Transfer Protocol (HTTP) transport methods and generally rely on file formats such as ISOBMFF. One such streaming system is Dynamic Adaptive Streaming over HTTP (DASH). Video can be encoded in video formats such as AVC and / or HEVC. The encoded video can be encapsulated in ISOBMFF tracks and included in DASH representations and segments. Important information about the video bitstream, such as profile, tier, level, etc., may be exposed as file format level metadata and / or as DASH Media Presentation Description (MPD) for content selection. For example, such information may be used to select appropriate media segments, both for initialization at the start of a streaming session and for stream adaptation during a streaming session.

[0038] Similarly, when an image format having ISOBMFF is used, a file format specification specific to the image format may be adopted, such as the AVC image file format and the HEVC image file format. The VVC video file format, which is a file format for storing VVC video content based on ISOBMFF, is being developed by MPEG. The VVC image file format, which is a file format for storing image content coded using VVC, based on ISOBMFF, is also being developed by MPEG.

[0039] Support for random access in HEVC and VVC is described below. Random access refers to starting access and decoding of a bitstream from a picture that is not the first picture of the bitstream in decoding order. To support tuning and channel switching in broadcast / multicast and multi-party video conferencing, local playback and searching in streaming, and stream adaptation in streaming, the bitstream should contain frequent random access points. Such random access points are typically intra-coded pictures, but may also be inter-coded pictures (e.g., in the case of gradual decoding refresh). An intra-coded picture is a picture that is coded with reference to blocks within the picture, and an inter-coded picture is a picture that is coded with reference to blocks of other pictures.

[0040] HEVC includes signaling of Intra Random Access Points (IRAP) pictures in the NAL unit header by the NAL unit type. HEVC supports three types of IRAP pictures: Instantaneous Decoder Refresh (IDR), Clean Random Access (CRA), and Broken Link Access (BLA). IDR pictures constrain the inter-picture prediction structure not to reference any pictures before the current Group-Of-Pictures (GOP) and are traditionally called Closed GOP Random Access Points. CRA pictures relax the restriction by allowing a picture to reference pictures before the current GOP, which are all discarded in the case of random access. CRA pictures are called Open GOP Random Access Points. BLA pictures are typically generated by splicing two bitstreams or parts of them at a CRA picture, for example at stream switching. To enable better system usage of IRAP pictures, six different NAL units are defined that signal properties of IRAP pictures and can be used to match the stream access point types defined by ISOBMFF (ISO Base Media File Format), which are also used for random access support in Dynamic Adaptive Streaming over HTTP (DASH).

[0041] VVC supports three types of IRAP pictures, two types of IDR pictures (one with an associated RADL picture and the other without an associated RADL picture) and one type of CRA picture, which are used in the same way as HEVC. The BLA picture type in HEVC is not included in VVC. This is because the basic function of a BLA picture can be realized by a CRA picture plus an end-of-sequence NAL unit, the presence of which indicates that the following picture starts a new CVS in a single-layer bitstream. Furthermore, there was a demand during the development of VVC to specify fewer NAL unit types than HEVC, as indicated by the use of 5 bits instead of 6 bits for the NAL unit type field of the NAL unit header.

[0042] Another difference in random access support between VVC and HEVC is that VVC supports GDR in a more prescriptive way. In GDR, bitstream decoding can start with an inter-coded picture. At the first picture at the random access point, only a part of the picture can be correctly decoded. However, after several pictures, the entire picture area can be correctly decoded and displayed. AVC and HEVC also support GDR using a recovery point SEI message for signaling GDR random access points and recovery points. In VVC, a NAL unit type is defined to indicate a GDR picture, and recovery points are signaled in the picture header syntax structure. CVS and bitstreams are allowed to start with a GDR picture. Thus, the entire bitstream can contain only inter-coded pictures, without any intra-coded pictures. The main advantage of defining GDR support in this way is to provide GDR-compatible operation. GDR allows an encoder to smooth the bitrate of the bitstream by distributing intra-coded slices or blocks (which are less compressed than inter-coded slices / blocks) across multiple pictures instead of intra-coding the entire picture. This allows for significant end-to-end delay reduction, which is considered more important due to the increasing use of ultra-low latency applications such as wireless displays, online gaming, drone-based applications, etc.

[0043] Another GDR-related feature in VVC is virtual boundary signaling. The boundary between refreshed (correctly decoded in GDR) and non-refreshed regions in pictures between the GDR picture and the recovery point can be signaled as a virtual boundary. If signaled, in-loop filtering across the boundary is not applied. This can avoid inconsistencies in the decoding of some samples at or near the boundary. This can be useful if an application decides to display correctly decoded regions during the GDR process. IRAP and GDR pictures can be collectively referred to as RAP (Random Access Point) pictures.

[0044] VUI and SEI messages are described below. VUI is a syntax structure transmitted as part of the SPS (and possibly also in the VPS for HEVC). VUI does not affect the standard decoding process, but carries information that can be used for proper rendering of the video being coded. SEI assists processes related to decoding, display, or other purposes. Like VUI, SEI does not affect the standard decoding process. SEI is carried in SEI messages. Decoder support for SEI messages is optional. However, SEI messages affect bitstream conformance. For example, if the syntax of SEI messages in a bitstream does not follow this specification, the bitstream is not conformant. Several SEI messages are used in the HRD specification.

[0045] The VUI syntax structure and most of the SEI messages used in VVC are not specified in the VVC specification, but are specified in the VSEI specification. SEI messages used for HRD conformance testing are specified in the VVC specification. VVC defines five SEI messages related to HRD conformance testing, and the VSEI specifies 20 additional SEI messages. The SEI messages carried in the VSEI specification do not directly affect the operation of a conforming decoder and are defined to be used in a coding format independent manner, allowing the VSEI to be used with other video coding standards in addition to VVC. Rather than specifically referencing VVC syntax element names, the VSEI specification refers to variables whose values ​​are set within the VVC specification.

[0046] Compared to HEVC, the VUI syntax structure in VVC focuses only on information related to the proper rendering of pictures and does not contain timing information or bitstream restriction indications. In VVC, the VUI is signaled within the SPS, which includes a length field before the VUI syntax structure, signaling the length of the VUI payload in bytes. This allows decoders to easily jump between information and allows VUI syntax extensions by adding new syntax elements directly at the end of the VUI syntax structure, similar to the syntax extensions of SEI messages.

[0047] The VUI syntax structure includes the following information: an indication of whether the content is interlaced or progressive, an indication of whether the content contains frame-packed stereoscopic or projected omnidirectional video, the sample aspect ratio, an indication of whether the content is suitable for overscan displays, a color description including color primaries, matrices, and transfer characteristics to support Ultra High Definition (UHD) vs. High Definition (HD) color spaces and High Dynamic Range (HDR) signaling, and an indication of chroma position relative to luma (compared to HEVC, signaling of progressive content is clarified).

[0048] If the SPS does not include a VUI, that information is considered unspecified and must be conveyed via external means or specified by the application if the bitstream's contents are intended to be rendered on a display.

[0049] Table 1 lists the SEI messages defined in VVC, including their syntax and semantics. Of the 20 SEI messages defined in the VVC specification, many are inherited from HEVC (e.g., the Filler Payload and both User Data SEI messages). Some SEI messages are utilized to correctly process or render the coded video content. This is the case for the Mastering Display Color Quantity, Content Light Level Information, and / or Alternate Transfer Characteristics SEI messages, which are particularly relevant for HDR content. Other examples include the Isotropic Projection, Spherical Rotation, Area-by-area Packing, and / or Omnidirectional Viewport SEI messages, which are relevant for signaling and processing 360° video content.

[0050] Table 1: List of SEI messages in VVC v1

[0051] [Table 1]

[0052] [Table 2]

[0053] The SEI messages specified in VVC v1 include a frame field information SEI message, a sample aspect ratio information SEI message, and a sub-picture level information SEI message. The frame field information SEI message includes information to indicate how the associated picture should be displayed (e.g., field parity or frame repetition period), the source scan type of the associated picture, and whether the associated picture is a duplicate of a previous picture. This information may be signaled together with the timing information of the associated picture in a picture timing SEI message in a video coding standard. However, frame field information and timing information are two different kinds of information that do not necessarily need to be signaled together. In a typical example, timing information is signaled at the system level, but frame field information is signaled in the bitstream. Therefore, frame field information is removed from the picture timing SEI message and instead signaled in a dedicated SEI message. This change also supports changing the syntax of the frame field information to convey additional and clearer instructions to the display, such as combining fields for frame repetition or pairing more values.

[0054] The sample-aspect ratio SEI message allows to signal different sample aspect ratios for different pictures in the same sequence, while the corresponding information contained in the VUI applies to the entire sequence. This may be relevant when using a reference picture resampling function with a scaling factor that causes different pictures of the same sequence to have different sample aspect ratios.

[0055] The sub-picture level information SEI message specifies the level information of a sub-picture sequence.

[0056] The DRAP indication SEI message is described below. The VSEI specification includes a DRAP indication SEI message, which is defined as follows:

[0057] [Table 3]

[0058] A picture associated with a Dependent Random Access (DRAP) indication SEI message is called a DRAP picture. The presence of a DRAP indication SEI message indicates that the picture ordering and picture referencing constraints specified in this section apply. These constraints may enable a decoder to properly decode the DRAP picture and pictures that follow the DRAP picture in both decoding order and output order without having to decode any other pictures other than the DRAP picture's associated IRAP picture.

[0059] The constraints indicated by the presence of a DRAP indication SEI message, which shall all apply, are: The DRAP picture is a trailing picture. The DRAP picture has a temporal sub-layer identifier equal to 0. The DRAP picture does not contain any pictures in the active entries of the DRAP picture's reference picture list, except for the DRAP picture's associated IRAP picture. Any picture following the DRAP picture in both decoding order and output order does not contain any pictures preceding the DRAP picture in decoding order or output order, in the active entries of that picture's reference picture list, except for the DRAP picture's associated IRAP picture.

[0060] DRAP signaling in media files is described below. ISOBMFF includes a signaling structure for DRAP based on sample groups as follows: DRAP sample groups are defined as follows: A DRAP sample is a sample that allows all samples in the decoding order to be correctly decoded if the closest initial sample preceding the DRAP sample is available for reference. An initial sample is a Stream Access Point (SAP) sample of SAP type 1, 2, or 3, and is either a Sync sample or is marked as such by a SAP sample group. For example, if the 32nd sample in a file is an initial sample containing an I-picture, then the 48th sample may contain a P-picture and be marked as a member of a subordinate random access point sample group. This indicates that random access can be performed at the 48th sample by first decoding the 32nd sample (ignoring samples 33-47) and then continuing decoding from the 48th sample.

[0061] A sample can be a member of a subordinate random access point sample group (hence called a DRAP sample) only if the following conditions are met: A DRAP sample only references the closest preceding initial sample. If decoding starts at a DRAP sample, the DRAP sample and all samples following the DRAP sample in output order can be correctly decoded. This can occur after decoding the closest preceding SAP sample of type 1, 2 or 3, which can be for example a sync sample or marked by a SAP sample group. A DRAP sample can only be used in conjunction with SAP samples of type 1, 2 and 3. This is to enable the ability to generate a sequence of decodable samples by concatenating the preceding SAP sample with the DRAP sample and the sample following the DRAP sample in output order. An exemplary syntax of a DRAP sample group is as follows: class VisualDRAPEntry() extends VisualSampleGroupEntry('drap'){ unsigned int(3) DRAP_type; unsigned int(29) reserved=0; }

[0062] Exemplary semantics for DRAP sample groups are as follows: DRAP_type is a non-negative integer. If DRAP_type is in the range 1 to 3, then DRAP_type indicates the SAP_type (specified in Annex I) to which the DRAP sample would have corresponded and the DRAP sample was independent of the closest previous SAP. Other type values ​​are reserved. Reserved shall be equal to 0. The semantics of this subclause apply only to sample group description entries reserved equal to 0. Parsers shall allow and ignore sample group description entries reserved greater than 0 when parsing this sample group.

[0063] In the following, a video coding approach based on Cross RAP Reference (CRR), also called External Decoding Refresh (EDR) and / or DRAP type 2, is described. The basic idea of ​​this video coding approach is as follows: Instead of coding random access points as intra-coded IRAP pictures (except for the very first picture in the bitstream), random access points are coded using inter prediction to avoid the unavailability of previous pictures when coded as IRAP pictures. This mechanism provides a limited number of previous pictures, typically pictures representing different scenes of the video content, via a separate video bitstream, which may be called an external stream and / or external means. Such previous pictures are called external pictures. As a result, each external picture can be used as a reference for inter prediction by pictures that straddle the random access point. An improvement in coding efficiency comes from coding random access points as inter-predicted pictures, making more reference pictures available for pictures that follow the EDR picture in decoding order. Bitstreams coded with such a video coding approach can be used for ISOBMFF and DASH based applications, as described below.

[0064] DASH content creation operations are described below. Video content is coded into one or more representations, each with a particular spatial resolution, temporal resolution, and quality. Each representation of the video content is represented by a main stream and possibly also by an outer stream. The main stream contains coded pictures that may or may not contain EDR pictures. If at least one EDR picture is included in the main stream, then an outer stream is also present, and this outer stream contains outer pictures. If no EDR pictures are included in the main stream, then there is no outer stream. Each main stream is carried in a Main Stream Representation (MSR). Each EDR picture in the MSR is the first picture of a segment.

[0065] Each external stream, if present, is carried in an External Stream Representation (ESR). For each segment in the MSR that starts with an EDR picture, there is a segment in the corresponding ESR with the same segment start time derived from the MPD, which carries the external pictures required to decode that EDR picture and subsequent pictures in decoding order in the bitstream carried in the MSR. MSRs of the same video content are included in one Adaptation Set (AS). ESRs of the same video content are included in one AS.

[0066] The DASH streaming operation is described below: A client obtains the MPD of a DASH Media Presentation, parses the MPD, selects an MSR, and determines the start presentation time for consuming the content. The client requests segments from the MSR, starting with the segment containing a picture with a presentation time equal to (or close enough to) the start presentation time. If the first picture of the start segment is an EDR picture, then the client also requests the corresponding segment in the associated ESR (with the same segment start time derived from the MPD) before requesting the MSR segment. Otherwise, no segment from the associated ESR is requested.

[0067] When switching to a different MSR, the client requests segments of the switch to the MSR starting from the first segment with a segment start time greater than the segment start time of the last requested segment of the switch from the MSR. If the first picture of the start segment in the destination MSR is an EDR picture, the corresponding segment in the associated ESR is also requested, preferably before requesting the MSR segment. Otherwise, no segment of the associated ESR is requested.

[0068] When continuously operating on the same MSR (after a search or stream switch operation, after decoding the starting segment), no segments of the associated ESR shall be requested, including when requesting any segment starting at an EDR picture.

[0069] In the following, the signaling of cross RAP reference in video is described. The CRR can be signaled in an SEI message called DRAP indication SEI message of type 2 as follows: The DRAP indication SEI message syntax of type 2 is as follows:

[0070] [Table 4]

[0071] The semantics of the type 2 DRAP indication SEI message are as follows: A picture associated with a type 2 DRAP indication SEI message is called a type 2 DRAP picture. A type 1 DRAP picture (associated with a DRAP indication SEI message) and a type 2 DRAP picture are collectively called a DRAP picture. The presence of a type 2 DRAP indication SEI message indicates that the picture order and picture referencing constraints specified in this subclause apply. These constraints allow a decoder to properly decode a type 2 DRAP picture and pictures that follow the type 2 DRAP picture in the same layer and in both decoding order and output order. This can be achieved without the need to decode other pictures in the same layer, except for the picture list referenceablePictures, which contains a list of IRAP or DRAP pictures in decoding order that are in the same CLVS and are identified by the t2drap_ref_rap_id[i] syntax element.

[0072] All constraints indicated by the presence of a type 2 DRAP indication SEI message shall apply, as follows: A type 2 DRAP picture is a trailing picture. A type 2 DRAP picture has a temporal sub-layer identifier equal to 0. A type 2 DRAP picture does not contain any pictures of the same layer in the active entries of the type 2 DRAP picture's reference picture list, except for referenceablePictures. Any pictures following a type 2 DRAP picture in the same layer and in both decoding order and output order, does not contain any pictures preceding the type 2 DRAP picture in the active entries of the type 2 DRAP picture's reference picture list, except for referenceablePictures, in the same layer and in decoding order or output order. Any pictures in the list referenablePictures do not contain any pictures in the active entries of the picture's reference picture list that are not pictures of the same layer and at an earlier position in the list referenceablePictures. As a result, the first picture in referenceablePictures does not have a picture from the same layer in the active entries of its reference picture list, even if the picture is a DRAP picture rather than an IRAP picture.

[0073] t2drap_rap_id_in_clvs specifies the RAP picture identifier of a type 2 DRAP picture, denoted as RapPicId. Each IRAP or DRAP picture is associated with a RapPicId. The value of RapPicId for an IRAP picture is inferred to be equal to 0. The value of RapPicId shall be different for any two IRAP or DRAP pictures in a CLVS. t2drap_reserved_zero_13bits shall be equal to 0 in bitstreams conforming to this version of the specification. Other values ​​of t2drap_reserved_zero_13bits are reserved. Decoders shall ignore the value of t2drap_reserved_zero_13bits. t2drap_num_ref_rap_pics_minus1+1 indicates the number of IRAP or DRAP pictures that are in the same CLVS as the DRAP picture of type 2 and may be included in the active entries of the reference picture list of the DRAP picture of type 2. t2drap_ref_rap_id[i] indicates the RapPicId of the i-th IRAP or DRAP picture that is in the same CLVS as the DRAP picture of type 2 and may be included in the active entries of the reference picture list of the DRAP picture of type 2.

[0074] Examples of technical problems that the disclosed technical proposal aims to solve are given below. For example, the signaling of CRR and / or DRAP in video bitstreams and media files has the following problems: The DRAP indication SEI message lacks signaling indicating whether a picture following the DRAP picture in decoding order and preceding the DRAP picture in output order can be correctly decoded when randomly accessed from the DRAP picture. Such a picture may be erroneously decoded in this case because it references a picture preceding the DRAP picture in decoding order for inter prediction.

[0075] Figure 5 shows an example of pictures that follow the associated DRAP picture in decoding order and precede the associated DRAP picture in output order. Each box is a picture shown in decoding order from left to right. The numbers in the boxes are the output order, also known as the picture order count of the pictures. The arrows indicate an inter-prediction relationship between two pictures with the picture on the right (arrow head) using the picture on the left (arrow origin) as a reference picture.

[0076] In the example shown in FIG. 5, inter prediction from picture 6 to picture 8 may be turned off (the arrow connecting the two pictures is removed). In this case, picture 8 can be correctly decoded when random access is performed from DRAP picture (picture 10). However, when inter prediction from picture 6 to picture 8 is used, picture 8 cannot be correctly decoded when DRAP picture (picture 10) is used as a random access point. Such an indication of whether inter prediction is turned off is useful for the system to know when to start presenting the video when random access is performed from a DRAP picture. For example, with such an indication, when random access is performed from DRAP picture (picture 10), the application system can know whether the presentation can start from picture 8 or from picture 10.

[0077] The type 2 DRAP indication SEI message also does not provide a signaling mechanism to indicate whether a picture that follows the type 2 DRAP picture in decoding order and precedes the type 2 DRAP picture in output order can be correctly decoded when randomly accessed from the type 2 DRAP picture. Such a picture may be erroneously decoded when referring to a picture that precedes the type 2 DRAP picture in decoding order for inter prediction. Such an indication would be useful for a system to determine when to start presenting video when randomly accessed from a type 2 DRAP picture. A mechanism for signaling the CRR in a media file is also lacking.

[0078] Furthermore, the semantics of the DRAP sample group in ISOBMFF is incorrect. In ISOBMFF, the DRAP sample is a sample that allows all samples in the decoding order to be correctly decoded if the closest initial sample preceding the DRAP sample is referable. However, even if the closest initial sample preceding the DRAP sample is referable, a sample following the DRAP sample in the decoding order and preceding the DRAP sample in the output order may refer to a picture that is earlier than the picture of the closest initial sample in the reference. In such a case, such a sample (picture) cannot be correctly decoded.

[0079] This specification discloses a mechanism that addresses one or more of the above-mentioned problems. For example, a DRAP picture is a random access point picture that is coded by inter prediction with reference to an IRAP picture. Furthermore, a CRR picture, also known as a type 2 DRAP and / or an Enhanced Dependent Random Access Point (EDRAP) picture, is a random access point picture that is coded via inter prediction with reference to an IRAP picture and is allowed to reference one or more other dependent random access point pictures. Thus, CRR / DRAP / type 2 DRAP are considered as a type of DRAP. DRAP and CRR are designed under the assumption that video pictures are managed in a specific order. However, an encoder is allowed to reorder pictures to improve coding efficiency. Thus, video pictures can have an output order and a decoding order. The output order is the order in which pictures are presented / displayed, and the decoding order is the order in which pictures are coded into a bitstream. Some designs of DRAP and CRR do not take such distinction into account, and therefore errors may occur when video is coded using DRAP and / or CRR and the encoder decides to reorder pictures. Specifically, an error may occur when an inter-predicted picture follows a DRAP / CRR picture in decoding order and precedes the DRAP / CRR picture in output order. Such a picture may be allowed to be coded with reference to a further picture that precedes the DRAP / CRR picture in decoding order, and therefore an error may occur. When a DRAP / CRR picture is used by a decoder as a random access point, the picture may or may not be fully decodable depending on whether inter prediction is used by referencing further pictures. Furthermore, various signaling mechanisms may not fully support DRAP and / or CRR.

[0080] Thus, the present disclosure includes a signaling mechanism for indicating whether an inter-predicted picture that follows a DRAP / CRR picture in decoding order and precedes the RAP / CRR picture in output order is allowed to reference other pictures preceding the DRAP / CRR picture. In one example, this signaling mechanism is an SEI message in the encoded bitstream. If such inter-prediction references are allowed, the inter-predicted picture is not displayed when using the DRAP / CRR picture as a random access point. If such inter-prediction references are prevented, the inter-predicted picture can be displayed when using the DRAP / CRR picture as a random access point. Furthermore, the present disclosure describes sample groups and / or sample entries that may be included in an ISOBMFF media file to describe the DRAP and / or CRR pictures. This allows a decoder to determine the presence and location of the DRAP and / or CRR pictures at the file format level.

[0081] In order to solve the above problems, the methods summarized below are disclosed. These items are examples for explaining the general concept and should not be interpreted in a narrow sense. Furthermore, these items may be applied individually or may be combined in any manner.

[0082] Example 1

[0083] In one example, an indication is added to the DRAP indication SEI message syntax to indicate whether a picture in the same layer as the DRAP picture, which follows the DRAP picture in decoding order and precedes the DRAP picture in output order, is allowed to reference a picture in the same layer that precedes the DRAP picture in decoding order for inter prediction. If such reference is prevented, the decoder can correctly decode and display such a picture when the DRAP is used as a random access point. If reference is permitted, decoding may not be possible and such a picture should not be displayed by the decoder when using the DRAP as random access. In one example, the indication is a one-bit flag. In one example, the flag is set equal to X (X is 1 or 0), indicating that a picture in the same layer following the DRAP picture in decoding order and preceding the DRAP picture in output order is allowed to reference a picture in the same layer that precedes the DRAP picture in decoding order for inter prediction. In one example, the flag may be set equal to 1-X (X is 1 or 0), indicating that a picture following the DRAP picture in decoding order in the same layer and preceding the DRAP picture in output order does not reference a picture that is earlier than the DRAP picture in decoding order in the same layer for inter prediction. In one example, the indication is a multi-bit indicator. In one example, the constraint requires that a picture following the DRAP picture in decoding order in the same layer follows a picture earlier than the DRAP picture in decoding order in the same layer in output order.

[0084] Example 2

[0085] In one example, an additional SEI message is specified, the presence of which indicates that a picture following the DRAP picture in the bitstream in decoding order in the same layer and preceding the DRAP picture in output order does not refer to a picture preceding the DRAP picture in decoding order in the same layer for inter prediction. In one example, the presence of this SEI message indicates that a picture following the DRAP picture in the bitstream in decoding order in the same layer and preceding the DRAP picture in output order is permitted to refer to a picture preceding the DRAP picture in decoding order in the same layer for inter prediction. In one example, the constraint requires that any picture following the DRAP picture in decoding order in the same layer follows any picture preceding the DRAP picture in decoding order in the same layer in output order.

[0086] Example 3

[0087] In one example, an additional SEI message is specified. The presence of this additional SEI message indicates that a picture following the DRAP picture associated with both the SEI message and the DRAP indication SEI message in decoding order in the same layer and preceding the DRAP picture in output order does not refer to a picture preceding the DRAP picture in decoding order in the same layer for inter prediction. In one example, the absence of this additional SEI message indicates that a picture following the DRAP picture associated with both the additional SEI message and the DRAP indication SEI message in decoding order in the same layer and preceding the DRAP picture in output order is permitted to refer to a picture preceding the DRAP picture in decoding order in the same layer for inter prediction. In one example, the constraint guarantees that any picture following the DRAP picture in decoding order in the same layer follows the picture preceding the DRAP picture in decoding order in output order.

[0088] Example 4

[0089] In one example, an additional SEI message is specified, and an indication is added to the additional SEI message syntax to indicate whether a picture following the DRAP picture associated with both the additional SEI message and the DRAP indication SEI message in decoding order in the same layer and preceding the DRAP picture in output order is permitted to reference a picture preceding the DRAP picture in decoding order in the same layer for inter prediction. In one example, the indication is a one-bit flag. In one example, the flag is set equal to X (X is 1 or 0), indicating that a picture following the DRAP picture in decoding order in the same layer and preceding the DRAP picture in output order is permitted to reference a picture preceding the DRAP picture in decoding order in the same layer for inter prediction. In one example, a flag is further set equal to 1-X (X is 1 or 0) to indicate that a picture following the DRAP picture in decoding order in the same layer and preceding the DRAP picture in output order does not inter-reference a picture preceding the DRAP picture in decoding order in the same layer for prediction. In one example, this indication is a multi-bit indicator. In one example, the constraint requires that a picture following the DRAP picture in decoding order in the same layer follows any picture preceding the DRAP picture in decoding order in the same layer in output order.

[0090] Example 5

[0091] In one example, an indication is added to the type 2 DRAP indication SEI message syntax. This indication indicates whether a picture following the type 2 DRAP picture in decoding order and preceding the type 2 DRAP picture in output order in the same layer is permitted to reference a picture preceding the type 2 DRAP picture in decoding order in the same layer for inter prediction. In one example, this indication is a 1-bit flag. In one example, the flag is set equal to X (X is 1 or 0), indicating that a picture following the DRAP picture in decoding order in the same layer and preceding the DRAP picture in output order is permitted to reference a picture preceding the DRAP picture in decoding order in the same layer for inter prediction. In one example, the flag is further set to 1-X (X is 1 or 0), indicating that a picture following the DRAP picture in decoding order in the same layer and preceding the DRAP picture in output order does not reference a picture preceding the DRAP picture in decoding order in the same layer. In one example, this flag is added by reusing one bit from the t2drap_reserved_zero_13bits field in the Type 2 DRAP indication SEI message syntax. In one example, the indication is a multi-bit indicator. In one example, the constraint requires that a picture following a DRAP picture in decoding order in the same layer follows in output order any picture preceding the DRAP picture in decoding order in the same layer.

[0092] Example 6

[0093] In another example, the indication is associated with a DRAP or a DRAP picture of type 2. In one example, the indication may be signaled for each DRAP or DRAP of type 2.

[0094] Example 7

[0095] In one example, an additional sample group is defined to signal the CRR in an ISOBMFF file (eg, samples containing type 2 DRAP pictures).

[0096] Example 8

[0097] In one example, the DRAP sample group is extended to signal a CRR (e.g., a sample that contains a type 2 DRAP picture) in an ISOBMFF file, for example, by using the version field of the sample for the group box (e.g., SampleToGroupBox or CompactSampleToGroupBox) or by using the grouping_type_parameter field (or a portion thereof) of the sample for the group box.

[0098] Example 9

[0099] In one example, the DRAP sample entry includes a field indicating the number of mandatory RAP (Random Access Point) samples required for random access from a member of the DRAP sample group. The mandatory RAP samples are either initial samples or DRAP samples. In one example, the DRAP sample entry further includes a field indicating the RAP identifier of the member of the DRAP sample group. In one example, the field indicating the RAP identifier is coded using 16 bits. In one example, the field indicating the RAP identifier is coded using 32 bits. In one example, the DRAP sample entry does not include a field indicating the RAP identifier of the member of the DRAP sample group. The RAP identifier may be signaled in the sub-sample information box, the sample auxiliary information size box, and / or another box. In one example, the DRAP sample entry does not include a field indicating the RAP identifier of the member of the DRAP sample group. In one example, the RAP identifier is a sample number. In one example, the DRAP sample entry further includes several fields indicating the RAP identifiers of the mandatory RAP samples required for random access from a member of the DRAP sample group. In one example, each field indicating the RAP identifier of a mandatory RAP sample is coded using 16 bits. In one example, each field indicating the RAP identifier of a mandatory RAP sample is coded using 32 bits. In one example, each field indicating the RAP identifier of a mandatory RAP sample directly represents the RAP identifier of the mandatory RAP sample. In one example, the fields indicating the RAP identifier of a mandatory RAP sample each represent the difference between the RAP identifiers of two RAP samples. In one example, the i-th field (i is equal to 0) of the fields indicating the RAP identifiers of the mandatory RAP samples represents the difference between the RAP identifier of the current sample (e.g., a sample of the current DRAP sample group) and the i-th RAP identifier of the first mandatory RAP sample.In one example, the i-th field (i is greater than 0) of the fields indicating the RAP identifiers of the mandatory RAP samples represents the difference between the RAP identifier of the (i-1)-th mandatory RAP sample and the RAP identifier of the i-th required RAP sample. In one example, the i-th field (i is greater than 0) of the fields indicating the RAP identifiers of the mandatory RAP samples represents the difference between the RAP identifier of the i-th mandatory RAP sample and the RAP identifier of the (i-1)-th mandatory RAP sample.

[0100] Example 10

[0101] In one example, a Dependent Random Access Point (DRAP) sample is a sample that allows all samples in both decoding and output order to be correctly decoded if the closest initial sample preceding the DRAP sample is a reference.

[0102] Some illustrative examples of the aspects discussed above are set out below, with relevant portions that have already been added or modified in bold underline and portions that have been deleted in bold italics.

[0103] In an implementation example, the syntax for the Type 2 DRAP indication SEI message is modified as follows:

[0104] [Table 5]

[0105] Furthermore, the semantics of the type 2 DRAP indication SEI message is modified as follows: A picture associated with a type 2 DRAP indication SEI message is called a type 2 DRAP picture. A type 1 DRAP picture (associated with a DRAP indication SEI message) and a type 2 DRAP picture are collectively called DRAP pictures. The presence of a type 2 DRAP indication SEI message indicates that the picture ordering and picture referencing constraints specified in this subclause apply. These constraints allow a decoder to properly decode a type 2 DRAP picture and the pictures that follow it in the same layer and in both decoding order and output order without having to decode other pictures in the same layer, except for a list of pictures referenceablePictures, which consists of a list of IRAP or DRAP pictures in decoding order that are in the same CLVS and are identified by the t2drap_ref_rap_id[i] syntax element.

[0106] All constraints indicated by the presence of a type 2 DRAP indication SEI message shall apply, as follows: A type 2 DRAP picture is a trailing picture. A type 2 DRAP picture has a temporal sub-layer identifier equal to 0. A type 2 DRAP picture does not contain pictures of the same layer in the active entry of its reference picture list, except for referenceablePictures. Any pictures that are in the same layer and that follow a type 2 DRAP picture in both decoding order and output order do not contain pictures that are in the same layer and that precede the type 2 DRAP picture in decoding order or output order, except for referenceablePictures, in the active entry of its reference picture list.

[0107] [ka]

[0108] Any picture in the list referenceablePictures does not contain a picture in the active entry of its reference picture list that is not also a picture in the same layer and earlier in the list referenceablePictures. NOTE - As a result, the first picture in referenceablePictures does not contain a picture from the same layer in the active entry of its reference picture list, even if it is a DRAP picture rather than an IRAP picture.

[0109] t2drap_rap_id_in_clvs specifies the RAP picture identifier for type 2 DRAP pictures, denoted as RapPicId. Each IRAP or DRAP picture is associated with a RapPicId. The value of RapPicId for an IRAP picture is inferred to be equal to 0. The value of RapPicId shall be different for any two IRAP or DRAP pictures in a CLVS. t2drap_reserved_zero_13bits shall be equal to 0 in bitstreams conforming to this version of the standard. Other values ​​for t2drap_reserved_zero_13bits are reserved for future use by ITU-T|ISO / IEC. Decoders shall ignore the value of t2drap_reserved_zero_13bits. t2drap_num_ref_rap_pics_minus1+1 indicates the number of IRAP or DRAP pictures that are in the same CLVS as the DRAP picture of type 2 and may be included in the active entries of the reference picture list of the DRAP picture of type 2. t2drap_ref_rap_id[i] indicates the RapPicId of the i-th IRAP or DRAP picture that is in the same CLVS as the DRAP picture of type 2 and may be included in the active entries of the reference picture list of the DRAP picture of type 2.

[0110] [ka]

[0111] [ka]

[0112] [ka]

[0113] [ka]

[0114] [ka]

[0115] [ka]

[0116] [ka]

[0117] Furthermore, the RAP_id field for each DRAP sample is signaled in the Sub-Sample Information box, the Sample Auxiliary Information Size box, or the Additional box.

[0118] [ka]

[0119] [ka]

[0120] In another implementation example, the RAP sample identifier of a RAP sample is defined to be equal to the sample number of the RAP sample, the RAP_Id of the current sample is the sample number of the current sample, and the variable RefRapId[i] represents the sample number of the i-th RAP sample.

[0121] In another implementation, the RAP_id field, if present in the sample group description, and the ref_RAP_id[i] field are coded using 32 bits.

[0122] FIG. 1 is a schematic diagram illustrating an exemplary mechanism for random access when decoding a bitstream with IRAP pictures. Specifically, FIG. 1 illustrates a bitstream 100 including an IRAP picture 101 and a non-IRAP picture 103. The IRAP picture 101 is a picture that is coded according to intra prediction and can be used as an access point to the bitstream 100. Intra prediction is the process of coding blocks of a picture by referencing other blocks in the same picture. A picture coded according to intra prediction can be decoded without referencing other pictures. On the other hand, a non-IRAP picture 103 is a picture that cannot be used as an access point and can be decoded after the associated IRAP picture 101 is decoded. For example, the non-IRAP picture 103 is usually coded according to inter prediction. Inter prediction is the process of coding blocks of a picture by referencing blocks of other pictures that are designated as reference pictures. A picture coded based on inter prediction can be correctly decoded only if all reference pictures of that picture have also been decoded. Both IRAP pictures 101 and non-IRAP pictures 103 may be designated as reference pictures for other non-IRAP pictures 103.

[0123] Depending on the coding technique, various types of IRAP pictures 101 can be used. In this example, the IRAP pictures 101 include IDR and CRA pictures. An IDR picture is an intra-coded picture that can be used as the first picture of a video sequence to be coded. A CRA picture is an intra-coded picture that enables the use of an associated leading picture. A leading picture is a picture that precedes the associated IRAP picture 101 in output order and follows the IRAP picture 101 in decoding order. A decoder can start decoding at the beginning of the bitstream 100. However, a user often wants to jump to a particular point in the bitstream and start watching from the selected point. Any point that a user can select as a starting point for decoding is called a random access point.

[0124] In general, any IRAP picture 101 can be used as a random access point. After an IRAP picture 101 is selected as a random access point, all associated non-IRAP pictures 103 (e.g., following the selected IRAP picture 101) can also be decoded. In this example, the user selected CRA4 for random access. The decoder can start decoding at CRA4 without decoding pictures before CRA4. This is because pictures following an IRAP picture are generally prevented from referencing pictures earlier than the IRAP picture. Thus, once CRA4 is selected as a random access point, the decoder can decode CRA4 for display and then decode the non-IRAP pictures 103 following CRA4 based on CRA4. This allows the decoder to start presenting the bitstream from a random access point (e.g., CRA4) without decoding pictures before the random access point.

[0125] Figure 2 is a schematic diagram showing an exemplary mechanism for random access when decoding a bitstream using a DRAP picture. Specifically, Figure 2 shows a bitstream 200 including an IRAP picture 201, a non-IRAP picture 203, and a DRAP picture 205. The IRAP picture 201 and the non-IRAP picture 203 may be substantially similar to the IRAP picture 101 and the non-IRAP picture 103, respectively. In this example, an IDR picture is used as the IRAP picture 201.

[0126] Also included is a DRAP picture 205. The DRAP picture 205 is a picture that is coded according to inter prediction and can be used as an access point to the bitstream 200. For example, each DRAP picture 205 can be coded by referring to the IRAP picture 201. FIG. 2 includes arrows indicating pictures coded according to inter prediction from the associated reference picture. As shown in the figure, each DRAP picture 205 is coded with reference to IDR0. In this way, any DRAP picture 205 can be used as a random access point as long as the decoder can decode the associated IRAP picture 201. In the illustrated example, DRAP4 is selected as the random access point. The decoder should recognize that the DRAP picture 205 is used in the bitstream 200 and recognize the IRAP picture 201 used as a reference picture for the DRAP picture 205, for example by signaling. The decoder can then decode IDR0 for use in random access and decode DRAP4 based on IDR0. The decoder can then decode the non-IRAP picture 203 that follows DRAP4 based on DRAP4. The decoder can begin presenting the decoded video at DRAP4.

[0127] Pictures coded according to inter prediction are more compressed than pictures coded according to intra prediction. Thus, the DRAP picture 205 is more compressed than the IRAP picture 101 in the bitstream 100. Thus, the use of the DRAP picture 205 reduces the number of data signaled in the bitstream 200 over time (e.g., bit rate) relative to the bitstream 100, at the cost of more complex signaling mechanisms and decoding processes.

[0128] Figure 3 is a schematic diagram of an exemplary mechanism of random access when decoding a bitstream using a CRR picture. Specifically, Figure 3 shows a bitstream 300 including an IRAP picture 301, a non-IRAP picture 303, and a CRR picture 305. The IRAP picture 301 and the non-IRAP picture 303 may be substantially similar to the IRAP picture 101 and the non-IRAP picture 103, respectively. The CRR picture 305 is a picture that is coded according to inter prediction and can be used as an access point to the bitstream 300. The CRR picture 305 may be considered as a kind of DRAP picture. While the DRAP picture is coded with reference to the IRAP picture, the CRR picture 305 can be coded with reference to both the IRAP picture 301 and any other CRR picture 305. Because a CRR picture 305 is a type of DRAP picture, the CRR picture 305 is also known as an EDRAP picture and / or a DRAP picture of type 2, and these terms can be used interchangeably. Figure 3 includes arrows that indicate pictures that are coded according to inter prediction from an associated reference picture.

[0129] In the illustrated example, all CRR pictures 305 are coded by referencing the IRAP picture 301, shown as IDR0. CRR3, CRR4, CRR5 are also coded by referencing CRR2. Thus, a decoder can use any CRR picture 305 as a random access point, as long as it can decode the associated IRAP picture 301 and the associated CRR picture 305 used as a reference picture. In the illustrated example, CRR4 is selected as a random access point. The decoder needs to know that a CRR picture 305 is used in the bitstream 300, and can know, for example by signaling, which IRAP picture 301 and which CRR picture 305 are used as reference pictures for other CRR pictures 305. The decoder can then decode IDR0 and CRR2 for use in random access, and decode CRR4 based on IDR0 and CRR2. The decoder can then decode the non-IRA P picture 303 following CRR4 based on CRR4. The decoder can start presenting the decoded video in CRR4.

[0130] Inter prediction works by matching a block in a picture with a similar reference block in a reference picture. Then, instead of encoding the current block, the encoder may encode a motion vector that points to the reference block. Any difference between the current block and the reference block is encoded as a residual. The closer the current block and the reference block match, the less residual is encoded. Thus, by better matching the current block and the reference block, less data is coded and compression is better. The advantage of CRR over DRAP is that more pictures can be used, resulting in better matching and better compression. CRR over DRAP has higher signaling and decoding costs.

[0131] FIG. 4 is a schematic diagram illustrating an example mechanism for signaling an external bitstream 401 to support random access based on CRR. As mentioned above, the management of reference pictures for CRR is more complicated than the management of reference pictures for DRAP. FIG. 4 illustrates a main bitstream 400 including encoded video to be decoded by a decoder. The main bitstream 400 is substantially similar to the bitstream 300, but the reference numbers are omitted for ease of explanation. The external bitstream 401 is used to support random access. Specifically, the external bitstream 401 includes a set of reference pictures corresponding to each CRR picture. When random access occurs, the encoder and / or video server can transmit the main bitstream 400 starting from the access point and the portion of the external bitstream 401 that corresponds to the access point. For example, a user can select CRR3 for random access. The decoder can then request the main bitstream 400 starting at CRR3. The encoder / video server can then start transmitting the main bitstream 400 at CRR3. The encoder / video server may also transmit the portion of the external bitstream 401 that corresponds to the random access point. In this example, the encoder / video server transmits IDR0 and CRR2. In this way, the decoder receives the CRR picture at the random access point and all reference pictures required to decode the CRR picture. The decoder can then decode CRR3 and start displaying the video from that point on. To reduce data transmission, the encoder / video server may transmit only the portion of the external bitstream 401 that is required to decode the random access point and not transmit any further data unless a random access occurs again and / or a subsequent CRR picture uses a reference picture that is not provided for the current random access point.

[0132] 5 is a diagram 500 illustrating potential decoding errors when a picture follows a DRAP and / or CRR picture in decoding order and precedes the DRAP and / or CRR picture in output order. As in the previous figure, arrows represent inter prediction by pointing towards the inter predicted picture and away from the associated reference picture.

[0133] An encoder can reorder pictures to improve compression. Thus, the order in which pictures should be presented to a user is known as output order. The order in which pictures are coded into a bitstream is known as decoding order. Pictures can be identified by a picture order count, which may be any value in ascending order that uniquely identifies a picture. In diagram 500, pictures are shown in decoding order. However, pictures are numbered based on the picture order count, which increases in output order. As can be seen from the picture order count, picture 8 is out of output order and follows picture 10, which is a random access point. Thus, picture 8 is an inter-predicted picture 503 that precedes the random access point in output order and follows the random access point in decoding order. In this example, picture 10 is a DRAP / CRR picture 505, which may be either a DRAP picture or a CRR / EDRAP / type 2 DRAP picture, depending on the example. In this example, inter-predicted picture 503 is coded via inter prediction with reference to picture 6 with reference to picture 507. Thus, picture 6 becomes reference picture 502 of inter-predicted picture 503.

[0134] Diagram 500 illustrates a potential coding error because inter-predicted picture 503 references reference picture 507 via inter prediction. Specifically, inter-predicted picture 503 references reference picture 502, which follows DRAP / CRR picture 505 in decoding order, precedes DRAP / CRR picture 505 in output order, and precedes DRAP / CRR picture 505 in decoding order (507). When decoding the bitstream from picture 4, which is an IRAP picture of type IDR, reference picture 502 is decoded and stored in the reference picture buffer, so that inter-predicted picture 503 can be correctly decoded. However, if DRAP / CRR picture 505 is used for random access, reference picture 502 is skipped and not decoded. Thus, if inter-predicted picture 503 references reference picture 502, inter-predicted picture 503 cannot be correctly decoded. The encoder has the option of not allowing reference 507. For example, the encoder may restrict every inter-predicted picture 503 to only refer to the picture of the associated random access point and the picture following the associated access point in decoding order. If reference 507 is not allowed, the inter-predicted picture 503 can always be decoded because the inter-predicted picture 503 is not allowed to refer to any picture before the DRAP / CRR picture 505. However, if reference 507 is allowed, if the encoder decides to encode the inter-predicted picture 503 to the reference picture 502 by reference 507, the inter-predicted picture 503 cannot be directly decoded. Note that allowing reference 507 does not necessarily cause an error because the encoder is not required to use reference 507. However, if reference 507 is allowed, an error occurs when reference 507 is selected and then the DRAP / CRR picture 505 is used for random access. This may result in seemingly random errors from the user's perspective, degrading the user's experience.

[0135] This disclosure includes several mechanisms to address this issue. For example, an encoder can signal to a decoder whether reference 507 is allowed. If reference 507 is allowed, the decoder should not display an inter-predicted picture 503 that precedes the DRAP / CRR picture 505 in output order and follows the DRAP / CRR picture 505 in decoding order when the DRAP / CRR picture 505 is used for random access, since the inter-predicted picture 503 may or may not be decoded (depending on whether the encoder chooses to use reference 507). If reference 507 is not allowed, the decoder should display an inter-predicted picture 503 associated with the DRAP / CRR picture 505 when the DRAP / CRR picture 505 is used for random access. Furthermore, the DRAP and CRR signaling mechanisms are not fully specified. Therefore, this disclosure includes a mechanism for signaling a description of the use of the DRAP and CRR in a media file to more efficiently decode the DRAP / CRR picture 505 and / or related pictures after random access by a decoder.

[0136] In another example, the coding process may be constrained so that the reference 507 does not occur. For example, pictures may be divided into layers, and each layer may be associated with a different frame rate. This allows the decoder to select a layer with a frame rate that the decoder can support. The decoder then displays all pictures of the selected layer and all pictures of layers below the selected layer to achieve the desired frame rate. The error shown in diagram 500 can be prevented if the encoder requires that a picture in the same layer as the DRAP / CRR picture 505 (e.g., inter-predicted picture 503) and following the DRAP / CRR picture 505 in decoding order follow in output order a picture in the same layer and preceding the DRAP / CRR picture in decoding order.

[0137] 6 is a schematic diagram illustrating a media file 600 stored in an ISOBMFF. For example, the media file 600 may be stored in an ISOBMFF and used as a DASH representation. The ISOBMFF media file 600 is stored in multiple boxes that carry objects and / or data associated with the media content or media presentation. For example, the media file 600 may comprise a file type box (e.g., ftyp) 630, a movie box (e.g., moov) 610, and a media data box (e.g., mdat) 620.

[0138] The file type box 630 may carry data that describes the entire file, and therefore may carry file-level data. Thus, a file-level box is any box that contains data related to the entire media file 600. For example, the file type box 630 may contain a file type that indicates a version number of the ISO standard and / or compatibility information for the media file 600. The movie box 610 may carry data that describes a movie contained in the media file, and therefore may carry movie-level data. A motion level box is any box that contains data that describes the entire movie contained in the media file 600. The movie box 610 may contain a wide range of sub-boxes that are used to contain data for various purposes. For example, the movie box 610 contains a track box (trak) that carries metadata that describes a track of the media presentation. Note that a track can be referred to as a timed sequence of related samples. For example, a media track may contain a series of pictures or sampled audio, and a metadata track may contain a series of metadata corresponding to these pictures and / or audio. The data that describes a track is track-level data, so any box that describes a track is a track-level box.

[0139] The media data box 620 comprises interleaved and time-ordered media data (e.g., video pictures and / or audio to be coded) of a media presentation. For example, the media data box 620 may contain a bitstream of video data coded according to VVC, AVC, HEVC, etc. The media data box 620 may contain video, audio, text or other media data for display to a user. In ISOBMFF, pictures, audio and text are collectively referred to as samples. This is in contrast to the terminology used in video coding standards, where a sample is a pixel to be coded / decoded. Thus, the term sample can refer to an entire picture (file format level) or a group of pixels (bitstream level), depending on the context.

[0140] As mentioned above, the present disclosure provides an additional mechanism for signaling the use of DRAP and / or CRR at the file format level. This allows a decoder to recognize the use of DRAP and / or CRR by loading parameters into the moov box 610 before actually decoding the bitstream of samples included in the mdat box 620. For example, the moov box 610 can include a DRAP sample group box 625 and / or an EDRAP sample group box 621. The sample group box can describe which samples are of the type corresponding to the sample group box. In one example, the DRAP and CRR are both described in the DRAP sample group box 625, for example, by treating the CRR as a subtype of DRAP. In another example, the CRR sample is described by the EDRAP sample group box 621, and the DRAP sample is described by the DRAP sample group box 625, respectively. In one example, the DRAP sample group 625 can include a DRAP sample entry 627. Each DRAP sample entry 627 can then describe an associated sample coded according to the DRAP. In one example, the EDRAP sample group 621 can include EDRAP sample entries 623. Each EDRAP sample entry 623 can then describe an associated sample coded based on a CRR / EDRAP / DRAP of type 2. Each DRAP / CRR sample description can include a sample identifier for the picture, an identifier for the sample that includes the associated reference picture, an indication of the number of samples and / or the number of RAP samples required to perform random access from the picture, and / or additional information that is useful to a decoder when selecting and performing random access in a DRAP / CRR picture.

[0141] The moov box 610 may also include a wide range of other boxes 629. In some examples, a description of the DRAP / CRR sample may be included in one or more of the other boxes 629. For example, the other box 629 may include a sample of a group box (SampleToGroupBox), and the DRAP and / or CRR sample may be described in the SampleToGroupBox. In another example, the other box 629 may include a compact sample of a group box (CompactSampleToGroupBox), and the DRAP and / or CRR sample may be described in the CompactSampleToGroupBox. As a specific example, the DRAP and / or CRR sample may be described in a group type parameter (group_type_parameter) field in the SampleToGroupBox and / or CompactSampleToGroupBox. In another example, the other box 629 may include a subsample information box, and the DRAP and / or CRR sample may be described in the subsample information box. In another example, other boxes 629 may include a sample auxiliary information size box, and the DRAP and / or CRR sample can be described in the sample auxiliary information size box. Additionally, any other box described herein may be included in other boxes 629 and may include a description of the DRAP and / or CRR sample.

[0142] FIG. 7 is a schematic diagram of a bitstream 700 including encoded visual media data. The bitstream 700 includes media data coded / compressed by an encoder for decoding / decompression by a decoder. For example, the bitstream 700 may be included in the media data box 620 of the ISOBMFF media file 600. Furthermore, the bitstream 700 may be included in a representation in DASH. The bitstream 700 may be coded according to various coding formats such as VVC, AVC, EVC, HEVC, etc. In some coding formats, the bitstream 700 is represented as a series of NAL units. A NAL unit is a data unit sized to be placed in a data packet. For example, VVC includes multiple types of NAL units. The bitstream 700 may include VCL (Video Coding Layer) NAL units that include video data and non-VCL NAL units that include data describing the VCL NAL units, describing the coding tools used, and describing coding constraints. In one example, the bitstream 700 may include a picture 710 coded in a VCL NAL unit. The picture 710 may be an IRAP picture, an inter-predicted picture, a DRAP picture, a CRR picture, etc. The non-VCL NAL unit may include various messages and parameter sets that describe the mechanism used to code the picture 710. Although many VCL NAL units are included in VVC, this disclosure focuses on SEI NAL units. For example, the SEI NAL unit may include an SEI message. The SEI NAL message includes data that aids in processing related to decoding, display, or other purposes, but is not required to determine sample values ​​of a picture being decoded in the decoding process. In one example, the SEI message may include a DRAP indication SEI message 716 and / or a type 2 DRAP indication SEI message 717.The DRAP indication SEI message 716 is an SEI message that includes data describing the use of a DRAP picture. The type 2 DRAP indication SEI message 717 is an SEI message that includes data describing the use of a CRR / EDRAP / type 2 DRAP picture. The DRAP indication SEI message 716 and / or the type 2 DRAP indication SEI message 717 may be associated with a DRAP and / or a CRR / EDRAP / type 2 DRAP picture and may indicate how such pictures should be treated during decoding.

[0143] In one example, the DRAP indication SEI message 716 may include an indication as to whether a picture following the DRAP picture in decoding order and preceding the DRAP picture in output order is permitted to refer to a reference picture located before the DRAP picture in decoding order for inter prediction. In one example, the DRAP indication SEI message 716 may include an indication as to whether a picture following the CRR / EDRAP / type 2 DRAP picture in decoding order and preceding the DRAP picture in output order is permitted to refer to a reference picture located before the DRAP picture in decoding order for inter prediction. In one example, the type 2 DRAP indication SEI message 717 may include an indication as to whether a picture following the CRR / EDRAP / type 2 DRAP picture in decoding order and preceding the DRAP picture in output order is permitted to refer to a reference picture located before the DRAP picture in decoding order for inter prediction. Thus, based on this example, the decoder can read the DRAP instruction SEI message 716 and / or type 2 DRAP instruction SEI message 717 and determine whether to present a picture that follows the DRAP / CRR picture in decoding order and precedes the DRAP / CRR picture in output order when using the DRAP / CRR picture as a random access point.

[0144] In a specific example, the DRAP indication SEI message 716 can be associated with a DRAP picture, and the type 2 DRAP indication SEI message 717 can be associated with a CRR / EDRAP / type 2 DRAP picture. In a further example, the type 2 DRAP indication SEI message 717 can include a T2drap_reserved_zero_13bits field 701, and a bit from the T2drap_reserved_zero_13bits field 701 can be used to indicate whether a picture following the CRR / EDRAP / type 2 DRAP picture in decoding order and preceding the DRAP picture in output order is permitted to refer to a reference picture located before the DRAP picture in decoding order for inter prediction. In another example, a field in the DRAP indication SEI message 716 can include a similar indication for a DRAP picture. In another example, a multi-bit indicator in the DRAP indication SEI message 716 and / or the type 2 DRAP indication SEI message 717 can be used for this purpose.

[0145] FIG. 8 is a block diagram illustrating an example video processing system 800 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 800. System 800 may include an input 802 for receiving video content. The video content may be received in a raw or uncompressed format, e.g., 8 or 10-bit multi-component pixel values, or may be received in a compressed or encoded format. Input 802 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, Passive Optical Network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

[0146] The system 800 may include a coding component 804 that may implement various coding or encoding methods described herein. The coding component 804 may reduce the average bit rate of the video from the input 802 to the output of the coding component 804, generating a coded representation of the video. Thus, this coding technique may be referred to as a video compression or video transcoding technique. The output of the coding component 804 may be stored or transmitted via a connected communication, as represented by component 806. The stored or communicated bitstream (or coded) representation of the video received at the input 802 may be used by component 808 to generate pixel values ​​or displayable video that are sent to the display interface 810. The process of generating video viewable by a user from the bitstream representation may be referred to as video unfolding. Additionally, although certain video processing operations are referred to as "coding" operations or tools, it will be understood that the coding tools or operations are used in an encoder, and that corresponding decoding tools or operations that reverse the results of the coding are performed by a decoder.

[0147] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI) or DisplayPort, etc. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), PCI, IDE interfaces, etc. The techniques described herein may be implemented in various electronic devices such as mobile phones, laptops, smartphones, or other devices capable of digital data processing and / or video display.

[0148] FIG. 9 is a block diagram illustrating an example of a video processing device 900. The device 900 may be used to implement one or more methods described herein. The device 900 may be implemented by a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 900 may include one or more processors 902, one or more memories 904, and video processing hardware 906. The one or more processors 902 may be configured to implement one or more methods described herein. The one or more memories 904 may be used to store data and code used to implement the methods and techniques described herein. The video processing hardware 906 may be used to implement the techniques described herein in a hardware circuit. In some embodiments, the video processing hardware 906 may be at least partially included in the processor 902, such as a graphics co-processor.

[0149] FIG. 10 is a flow chart of an example method 1000 of video processing. The method 1000 includes, at step 1002, determining (e.g., signaling) a description of a CRR sample in an ISOBMFF visual media data file. At step 1004, a conversion is performed between the visual media data and the visual media data file based on the CRR sample group. The description of the CRR sample can be included in various locations in the ISOBMFF media file. For example, the description of the CRR sample can be included in a CRR sample group, a type 2 DRAP sample group, an EDRAP sample group, and / or a DRAP sample group. In some examples, the description of the CRR sample can be included in a SampleToGroupBox and / or a CompactSampleToGroupBox, e.g., in a group_type_parameter field. In some examples, the CRR sample may be indicated as a type 2 DRAP sample and / or an EDRAP sample. Furthermore, in this context, each sample includes an encoded picture.

[0150] The description of the CRR sample may include one or more sample identifiers to identify samples that belong to (e.g., are included in) a sample group. In another example, the description of the CRR sample may include an identifier of a reference picture for the CRR sample. In another example, the description of the CRR sample may include a number of samples that need to be referenced to decode the current sample. In one example, the description of the CRR sample may be included in a sample entry in a sample group. In some examples, the visual media data file may be constrained to support proper decoding. For example, the visual media data file may be constrained such that the current sample is one of the CRR samples only if the current sample only references the closest previous initial sample, one or more CRR samples that precede the current sample in decoding order, or a combination thereof. In another example, the visual media data file may be constrained such that the current sample is one of the CRR samples only if the current sample and all samples following the current sample in decoding order and output order can be correctly decoded when decoding begins at the current sample. In another example, the visual media data file may be constrained such that the current sample is one of the CRR samples only if the current sample and all samples following the current sample can be correctly decoded after decoding the closest previous initial sample, one or more CRR samples that precede the current sample in decoding order, and combinations thereof.

[0151] 11 is a block diagram illustrating an example video coding system 1100 that may utilize techniques of this disclosure. As shown in FIG. 11, the video coding system 1100 may include a source device 1110 and a destination device 1120. The source device 1110 generates encoded video data, which may also be referred to as a video encoding device. The destination device 1120 may decode the encoded video data generated by the source device 1110 and may be referred to as a video decoding device.

[0152] The source device 1110 may include a video source 1112, a video encoder 1114, and an input / output (I / O) interface 1116. The video source 1112 may include a source such as a video capture device, an interface for receiving video data from a video content provider, and / or a computer graphics system for generating the video data, or a combination of these sources. The video data may include one or more pictures. The video encoder 1114 encodes the video data from the video source 1112 and generates a bitstream. The bitstream may include a sequence of bits that form a coded representation of the video data. The bitstream may include a coded picture and associated data. A coded picture is a coded representation of a picture. The associated data may include a sequence parameter set, a picture parameter set, and other syntax structures. The I / O interface 1116 may include a modulator / demodulator (modem) and / or a transmitter. The coded video data may be transmitted directly to the destination device 1120 via the I / O interface 1116 over the network 1130. The encoded video data may also be stored on a storage medium / server 1140 for access by the destination device 1120 .

[0153] The destination device 1120 may include an I / O interface 1126, a video decoder 1124, and a display device 1122. The I / O interface 1126 may include a receiver and / or a modem. The I / O interface 1126 may obtain the encoded video data from the source device 110 or the storage medium / server 1140. The video decoder 1124 may decode the encoded video data. The display device 1122 may display the decoded video data to a user. The display device 1122 may be integrated with the destination device 1120 or may be external to the destination device 1120 that may be configured to interface with an external display device.

[0154] Video encoder 1114 and video decoder 1124 may operate in accordance with a video compression standard, such as the High Efficiency Video Coding (HEVC) standard, the Versatile Video Coding (VVC) standard, and other current and / or future standards.

[0155] 12 is a block diagram illustrating an example of a video encoder 200, which may be the video encoder 114 in the system 100 shown in FIG. 11. The video encoder 1200 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 12, the video encoder 200 includes multiple functional components. The techniques described in this disclosure may be shared among various components of the video encoder 1200. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.

[0156] The functional components of the video encoder 1200 may include a partitioning unit 1201, a prediction unit 1202, a residual generation unit 1207, a transform processing unit 1208, a quantization unit 1209, an inverse quantization unit 1210, an inverse transform unit 1211, a reconstruction unit 1212, a buffer 1213, and an entropy coding unit 1214, and the prediction unit 1202 may include a mode selection unit 1203, a motion estimation unit 1204, a motion compensation unit 1205, and an intra prediction unit 1206, and the prediction unit 1202 may include a mode selection unit 1203, a motion estimation unit 1204, a motion compensation unit 1205, and an intra prediction unit 1206.

[0157] In other examples, the video encoder 1200 may include more, fewer, or different functional components. In one example, the predictor 1202 may include an Intra Block Copy (IBC) unit. The IBC unit may perform prediction in an IBC mode where at least one reference picture is the picture in which the current video block is located.

[0158] Furthermore, some components, such as the motion estimator 1204 and the motion compensator 1205, may be highly integrated, but are depicted separately in the example of FIG. 12 for purposes of illustration.

[0159] The divider 1201 may divide a picture into one or more video blocks. The video encoder 1200 and the video decoder 1300 may support a variety of video block sizes.

[0160] The mode selector 1203 may, for example, select one of intra or inter coding modes based on the error result, provide the resulting intra or inter coded block to the residual generator 1207, generate and provide residual block data to the reconstruction unit 1212, and reconstruct the coded block for use as a reference picture. In some examples, the mode selector 1203 may select a combination of Intra and Inter Prediction (CIIP) modes, in which prediction is based on an inter prediction signal and an intra prediction signal. The mode selector 1203 may select a resolution of the motion vector for the block (e.g., sub-pixel or integer pixel precision) in the case of inter prediction.

[0161] To perform inter prediction on a current video block, motion estimation unit 1204 may generate motion information for the current video block by comparing the current video block to one or more reference frames from buffer 1213. Motion compensation unit 1205 may determine a predicted video block for the current video block based on the motion information and decoded samples of pictures from buffer 1213 other than the picture associated with the current video block.

[0162] Motion estimation unit 1204 and motion compensation unit 1205 may perform different operations on the current video block depending on whether the current video block is an I-slice, a P-slice, or a B-slice, for example.

[0163] In some examples, the motion estimator 1204 may perform unidirectional prediction on the current video block, and the motion estimator 1204 may search for a reference picture in list 0 or list 1 for a reference video block for the current video block. The motion estimator 1204 may generate a reference index indicating a reference picture in list 0 or list 1 that contains the reference video block, and a motion vector indicating a spatial displacement between the current video block and the reference video block. The motion estimator 1204 may output the reference index, the prediction direction indicator, and the motion vector as motion information for the current video block. The motion compensation unit 1205 may generate a predicted video block for the current block based on the reference video block indicated by the motion information of the current video block.

[0164] In another example, motion estimator 1204 may perform bidirectional prediction for the current video block, and motion estimator 1204 may search reference pictures in list 0 for a reference video block for the current video block and may search reference pictures in list 1 for another reference video block for the current video block. Motion estimator 1204 may generate reference indexes indicating reference pictures in list 0 and list 1 that contain reference video blocks, and motion vectors indicating spatial displacements between the reference video blocks and the current video block. Motion estimator 1204 may output the reference index and the motion vector for the current video block as motion information for the current video block. Motion compensation unit 1205 may generate a predicted video block for the current video block based on the reference video blocks indicated by the motion information of the current video block.

[0165] In some examples, the motion estimator 1204 may output a full set of motion information for a decoder's decoding process. In some examples, the motion estimator 1204 may not output a full set of motion information for the current picture. Rather, the motion estimator 1204 may signal motion information of the current video block by reference to motion information of another video block. For example, the motion estimator 1204 may determine that the motion information of the current video block is sufficiently similar to the motion information of a neighboring video block.

[0166] In one example, the motion estimator 1204 may indicate, in a syntax structure associated with the current video block, a value that indicates to the video decoder 1300 of FIG. 13 that the current video block has the same motion information as another video block.

[0167] In another example, motion estimator 1204 may identify another video block and a motion vector difference (MVD) in a syntax structure associated with the current video block. The motion vector difference indicates a difference between the motion vector of the current video block and the motion vector of the indicated video block. Video decoder 1300 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0168] As mentioned above, the video encoder 1200 may predictively signal motion vectors. Two examples of predictive signaling techniques that may be implemented by the video encoder 1200 include Advanced Motion Vector Prediction (AMVP) and merge mode signaling.

[0169] The intra predictor 1206 may perform intra prediction on the current video block. When the intra predictor 1206 performs intra prediction on the current video block, the intra predictor 1206 may generate prediction data for the current video block based on decoded samples of other video blocks in the same picture. The prediction data for the current video block may include a predicted video block and various syntax elements.

[0170] Residual generator 1207 may generate residual data for the current video block by subtracting the predicted video block of the current video block from the current video block. The residual data for the current video block may include residual video blocks that correspond to different sample components of the samples in the current video block.

[0171] In other examples, for example in skip mode, there may be no residual data for the current video block, and residual generator 1207 may not perform the subtraction operation.

[0172] Transform processor 1208 may generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to a residual video block associated with the current video block.

[0173] After the transform processing unit 1208 generates a transform coefficient image block associated with the current image block, the quantization unit 1209 may quantize the transform coefficient image block associated with the current image block based on one or more Quantization Parameter (QP) values ​​associated with the current image block.

[0174] The inverse quantization unit 1210 and the inverse transform unit 1211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient image block to reconstruct a residual video block from the transform coefficient image block. The reconstruction unit 1212 may add the reconstructed residual video block to corresponding samples from one or more predicted video blocks generated by the prediction unit 1202 to generate a reconstructed video block associated with the current block for storing in the buffer 1213.

[0175] After the reconstructor 1212 reconstructs the video block, a loop filtering operation may be performed to reduce video blocking artifacts in the video block.

[0176] The entropy encoder 1214 may receive data from other functional components of the video encoder 1200. Once the entropy encoder 1214 receives the data, the entropy encoder 1214 may perform one or more entropy encoding operations to generate entropy coded data, and output a bitstream including the entropy coded data.

[0177] FIG. 13 is a block diagram illustrating an example of a video decoder 1300, which may be the video decoder 1124 in the system 1100 shown in FIG.

[0178] The video decoder 1300 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 13, the video decoder 1300 includes multiple functional components. The techniques described in this disclosure may be shared among various components of the video decoder 1300. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.

[0179] In the example of Figure 13, the video decoder 1300 includes an entropy decoding unit 1301, a motion compensation unit 1302, an intra prediction unit 1303, an inverse quantization unit 1304, an inverse transform unit 1305, a reconstruction unit 1306, and a buffer 1307. The video decoder 1300 may, in some examples, perform a decoding path that is approximately the reverse of the encoding path described with respect to the video encoder 1200 (Figure 12).

[0180] The entropy decoder 1301 may retrieve an encoded bitstream. The encoded bitstream may include entropy coded video data (e.g., coded blocks of video data). The entropy decoder 1301 may decode the entropy coded video data, and from the entropy decoded video data, the motion compensation unit 1302 may determine motion information including motion vectors, motion vector precision, reference picture list index, and other motion information. The motion compensation unit 1302 may determine such information, for example, by performing AMVP and merge mode.

[0181] The motion compensation unit 1302 may generate motion compensated blocks, possibly performing the interpolation based on an interpolation filter. An identifier for the interpolation filter to be used with sub-pixel accuracy may be included in the syntax element.

[0182] The motion compensation unit 1302 may calculate interpolated values ​​for sub-integer pixels of the reference block using an interpolation filter as used by the video encoder 1200 during encoding of the video block. The motion compensation unit 1302 may determine the interpolation filter used by the video encoder 1200 according to the received syntax information and generate a prediction block using the interpolation filter.

[0183] The motion compensation unit 1302 may use some of the following information to decode the encoded video sequence: syntax information to determine the size of blocks used to code frames and / or slices of the encoded video sequence, partitioning information describing how each macroblock of a picture of the encoded video sequence is divided, a mode indicating how each partition is coded, one or more reference frames (and reference frame lists) for each inter-coded block, and other information to decode the encoded video sequence.

[0184] The intra predictor 1303 may form a prediction block from spatially adjacent blocks, for example, using an intra prediction mode received in the bitstream. The inverse quantizer 1304 inverse quantizes (i.e., de-quantizes) the quantized video block coefficients provided in the bitstream and decoded by the entropy decoder 1301. The inverse transformer 1305 applies an inverse transform.

[0185] The reconstruction unit 1306 may sum the residual blocks with corresponding prediction blocks generated by the motion compensation unit 1302 or intra prediction unit 1303 to form decoded blocks. If desired, a deblocking filter may be applied to filter the decoded blocks to remove blocking artifacts. The decoded video blocks are stored in a buffer 1307, which provides reference blocks for subsequent motion compensation / intra prediction and generates decoded video for display on a display device.

[0186] FIG. 14 is a circuit diagram of an exemplary encoder 1400. The encoder 1400 is suitable for implementing the technique of VVC. The encoder 1400 includes three in-loop filters, namely, a Deblocking Filter (DF) 1402, a Sample Adaptive Offset (SAO) 1404, and an Adaptive Loop Filter (ALF) 1406. Unlike the DF 1402, which uses a predefined filter, the SAO 1404 and the AKF 1406 utilize the original samples of the current picture to add an offset, together with coded side information signaling the offset and filter coefficients, and also apply a Finite Impulse Response (FIR) filter to reduce the mean square error between the original samples and the reconstructed samples, respectively. The ALF 1406 is located at the last processing stage of each picture and can be considered as a tool that tries to catch and correct artifacts generated in the previous stage.

[0187] The encoder 1400 further includes an intra prediction component 1408 configured to receive an input video, and a motion estimation / motion compensation (ME / MC) component 1410. The intra prediction component 1408 is configured to perform intra prediction, and the ME / MC component 1410 is configured to perform inter prediction using reference pictures obtained from a reference picture buffer 1412. Residual blocks from the inter or intra prediction are provided to a transform (T) component 1414 and a quantization (Q) component 1416 to generate quantized residual transform coefficients, which are provided to an entropy coding component 1418. The entropy coding component 1418 entropy codes the prediction results and the quantized transform coefficients and transmits them to a video decoder (not shown). The quantized components output from the quantization component 1416 may be provided to an inverse quantization (IQ) component 1420, an inverse transform component 1422, and a reconstruction (REC) component 1424. The REC module 1424 can output pictures to the DF 1402, the SAO 1404, and the ALF 1406, and can filter these pictures before being stored in the reference picture buffer 1412.

[0188] Next, some suitable solutions are listed by way of examples.

[0189] The following solutions provide examples of the techniques considered herein.

[0190] 1. A visual media processing method (e.g., method 1000 shown in FIG. 10) includes performing a conversion between a video including a picture and a bitstream of the video (1004), wherein the picture is coded in the bitstream as a Dependent Random Access Point (DRAP) picture, the bitstream conforming to a format rule, the format rule specifying whether a syntax element is included in a Supplemental Enhancement Information (SEI) message indicating whether one or more pictures of the same layer as the DRAP picture that follow the DRAP picture in decoding order and precede the DRAP picture in output order reference pictures of the same layer for inter prediction, and the picture is prior to the DRAP in decoding order.

[0191] 2. The method according to solution 1, wherein the SEI message is a DRAP indication SEI message.

[0192] 3. The method according to solution 1, wherein the SEI message is different from the DRAP indication SEI message included in the bitstream.

[0193] 4. A method according to any one of Solutions 2 to 3, wherein the format rule specifies that the presence of an SEI message indicates that one or more pictures of the same layer as the DRAP picture that follow the DRAP picture in decoding order and precede the DRAP picture in output order are allowed to reference pictures of the same layer for inter prediction, and the pictures are earlier than the DRAP picture in decoding order.

[0194] 5. A method according to any one of Solutions 2 to 3, wherein the format rules specify that the presence of an SEI message indicates that one or more pictures of the same layer as the DRAP picture that follow the DRAP picture in decoding order and precede the DRAP picture in output order are not permitted to reference pictures of the same layer for inter prediction, and the pictures precede the DRAP picture in decoding order.

[0195] 6. The method according to any one of solutions 1 to 5, wherein the syntax element includes a one-bit flag.

[0196] The following solutions represent exemplary implementations of the techniques discussed in the previous section.

[0197] 7. A method of video processing comprising performing a conversion between video including one or more pictures and a bitstream of the video, the bitstream including a type 2 Dependent Random Access Point (DRAP) picture, the bitstream conforming to a format rule, the format rule specifying that the bitstream includes a specific type of Dependent Random Access Point (DRAP) indication syntax message for indicating whether a picture in a layer that follows the type 2 DRAP picture in decoding order and precedes the type 2 DRAP picture in output order is allowed to reference a picture in a layer that is before the type 2 DRAP picture in decoding order for inter prediction.

[0198] 8. The method according to solution 7, wherein the particular type of the DRAP instruction syntax message corresponds to a DRAP instruction syntax message of type 2.

[0199] 9. The method according to solution 7, wherein a particular type of DRAP instruction syntax message corresponds to a DRAP instruction syntax message.

[0200] 10. The method according to any one of solutions 7 to 9, wherein the syntax element includes a one-bit flag.

[0201] The following solutions represent exemplary implementations of the techniques discussed in the previous section.

[0202] 11. A method of video processing includes performing a conversion between video and a bitstream of video, the bitstream conforming to format rules that specify whether and how a Cross-Random access point Reference (CRR) is signaled in a file format that stores the bitstream.

[0203] 12. The method according to solution 11, wherein the formatting rules define sample groups that indicate CRR.

[0204] 13. The method according to solution 11, wherein the format rule defines that a Dependent Random Access Point (DRAP) sample group contains a CRR.

[0205] 14. The method according to solution 13, wherein the DRAP sample group for signaling a CRR includes a version field or a grouping_type_parameter field for signaling a CRR.

[0206] The following solutions represent exemplary implementations of the techniques discussed in the previous section.

[0207] 15. A method of video processing comprising performing a conversion between video and a video bitstream, the bitstream conforming to a format rule specifying that if the bitstream contains a Dependent Random Access Point (DRAP) picture, a field is included in a DRAP sample entry field indicating the number of Random Access Point (RAP) samples required for random access from members of the DRAP sample group.

[0208] 16. The method of solution 15, wherein the format rules further specify the inclusion of another field indicating the RAP identifiers of members of the DRAP sample group.

[0209] The following solutions represent exemplary implementations of the techniques discussed in the previous section.

[0210] 17. The method according to any one of solutions 1 to 16, wherein a Dependent Random Access Point (DRAP) sample is a sample that allows all samples to be correctly decoded in both decoding order and output order if the closest initial sample preceding the DRAP sample can be used for reference.

[0211] 18. The method according to any one of solutions 1 to 17, further comprising storing the bitstream in a file compliant with the file format.

[0212] 19. A method according to any one of solutions 1 to 17, wherein the bitstream is read from a file compliant with a file format.

[0213] 20. The method according to any one of solutions 18 to 19, wherein the file format is ISOBMFF (International Standard Organization Base Media File Format).

[0214] 21. A video decoding device comprising a processor configured to implement a method according to one or more of solutions 1 to 20.

[0215] 22. A video encoding device comprising a processor configured to implement a method according to one or more of solutions 1 to 20.

[0216] 23. A computer program product having computer code stored thereon, the code causing the processor to implement a method according to any one of solutions 1 to 20 when executed by the processor.

[0217] 24. A computer-readable medium carrying a bitstream compliant with a bitstream format generated according to any of solutions 1 to 20.

[0218] 25. A method comprising generating a bitstream according to the method of any one of solutions 1 to 20 and writing the bitstream to a computer-readable medium.

[0219] 26. Any method, apparatus or system described herein.

[0220] In the solutions described herein, an encoder may comply with the format rules by generating a coded representation according to the format rules. In the solutions described herein, a decoder may use the format rules to parse syntax elements in the coded representation with knowledge of the presence or absence of the syntax elements according to the format rules to generate decoded video.

[0221] In this specification, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of a current video block may correspond to bits spread to the same or different locations in the bitstream, for example, as specified by the syntax. For example, one macroblock may be coded in terms of a transformed and coded error residual value, and coded using bits in a header and other fields in the bitstream. Furthermore, during conversion, the decoder may parse the bitstream with the knowledge that some fields may or may not be present based on the determination, as described in the above solution. Similarly, the encoder may determine whether a particular syntax field should or should not be included in the coded representation and generate the coded representation accordingly by including or excluding the syntax field in the coded representation.

[0222] Implementations of the solutions, examples, embodiments, modules, and functional operations disclosed herein, including the structures disclosed herein and their structural equivalents, may be implemented in digital electronic circuitry, or computer software, firmware, or hardware, or in one or more combinations thereof. The disclosed and other embodiments may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for implementation by or for controlling the operation of a data processing apparatus. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter that provides a machine-readable propagated signal, or one or more combinations thereof. The term "data processing apparatus" includes all apparatus, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors, or computers. In addition to hardware, the apparatus may include code that creates an environment for the execution of the computer program, such as code that constitutes a processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof. A propagated signal is an artificially generated signal, for example a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to an appropriate receiving device.

[0223] A computer program (also called a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be recorded as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), may be stored in a single file dedicated to the program, or may be stored in multiple coordinating files (e.g., files that store one or more modules, subprograms, or code portions). A computer program can be deployed to run on one computer, or it can be deployed to run on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0224] The processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC).

[0225] Processors suitable for executing a computer program include, for example, both general purpose and special purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Typically, a computer may include one or more mass storage devices, such as magnetic, magneto-optical, or optical disks, for storing data, or may be operatively coupled to receive data from or transfer data to these mass storage devices. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash storage devices, magnetic disks, e.g., internal hard disks or removable disks, magneto-optical disks, and semiconductor storage devices such as Compact Disc Read-Only Memory (CD-ROM) and Digital Versatile Disc-Read Only Memory (DVD-ROM) disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0226] Although this patent specification includes many features, these should not be construed as limiting the scope of any subject matter or the scope of the claims, but rather as descriptions of features that may be specific to particular embodiments of a particular technology. Certain features described in this patent document in the context of separate embodiments may be implemented in combination in one example. Conversely, various features described in the context of one example may be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in a particular combination and initially claimed as such, one or more features from a claimed combination may, in some cases, be extracted from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0227] Similarly, although operations are shown in a particular order in the figures, this should not be understood as requiring that such operations be performed in the particular order or sequential order shown, or that all of the operations shown be performed, to achieve desired results, nor should the separation of various system components in the embodiments described in this patent specification be understood as requiring such separation in all embodiments.

[0228] Only some implementations and examples have been described; other embodiments, extensions and variations are possible based on the content described and illustrated in this patent specification.

[0229] A first component is directly coupled to a second component when there are no intervening components, other than lines, traces, or another medium, between the first and second components. A first component is indirectly coupled to a second component when there are intervening components, other than lines, traces, or other medium, between the first and second components. The term "coupled" and variations thereof include both direct and indirect couplings. Use of the term "about" connotes a range that includes ±10% of the subsequent number, unless otherwise specified.

[0230] Although several examples have been provided in this disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the disclosure. The examples should be considered as illustrative and not restrictive, and the invention should not be limited to the details set forth herein. For example, various elements or components may be combined or integrated in another system, or certain features may be omitted or not implemented.

[0231] Additionally, the techniques, systems, subsystems, and methods described and illustrated individually or separately in various examples may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the disclosure. Other items illustrated or described as being coupled may be directly connected, indirectly coupled, or communicate electrically, mechanically, or otherwise, through some interface, device, or intermediate component. Other examples of modifications, substitutions, and alterations may be ascertained by those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims

1. 1. A method for processing video data, comprising the steps of: Determining a description of a Cross Random access point Referencing (CRR) sample in ISOBMFF (International Organization for Standardization Base Media File Format) visual media data; performing a conversion between visual media data and the visual media data file based on the group of CRR samples; The method according to claim 1,

2. The method of claim 1 , wherein the description of the CRR sample is included in a group of CRR samples.

3. The method of claim 1 , wherein the CRR sample description is included in a group of Dependent Random Access Point (DRAP) samples.

4. The method of claim 1 , wherein the CRR sample description is included in a group of Type 2 DRAP samples.

5. The method of claim 1 , wherein the CRR sample description is included in a group of Enhanced Dependent Random Access Point (EDRAP) samples.

6. The method of claim 1 , wherein the CRR sample description is contained in a SampleToGroupBox.

7. The method of claim 1 , wherein the CRR sample description is contained in a CompactSampleToGroupBox.

8. The method of claim 1 , wherein the description of the CRR sample is included in a group_type_parameter field.

9. The method of claim 1 , wherein the CRR sample is denoted as a Type 2 DRAP sample.

10. The method of claim 1 , wherein the CRR samples are denoted as Enhanced Dependent Random Access Point (EDRAP) samples.

11. The method of claim 1 , wherein each sample comprises a picture.

12. The method of claim 1 , wherein the CRR sample description includes one or more identifiers for identifying samples belonging to a sample group.

13. The method of claim 1 , wherein the description of the CRR sample includes an identifier of a reference picture for the CRR sample.

14. The method according to claim 1 , wherein the description of the CRR sample includes the number of samples that need to be referenced to decode the current sample.

15. The method of claim 1 , wherein the description of the CRR sample is included in a sample entry of a sample group.

16. 16. The method of claim 1, wherein if the current sample references only the closest preceding initial sample, one or more CRR samples that precede the current sample in decoding order, or a combination thereof, the current sample is one of the CRR samples.

17. 17. The method of claim 1, wherein a current sample is one of the CRR samples if the current sample and all samples following it in decoding order and output order can be correctly decoded when decoding starts at the current sample.

18. 18. The method of claim 1, wherein the current sample and all samples following the current sample are correctly decoded after a closest preceding initial sample, one or more samples preceding the current sample in decoding order, or a combination thereof, are decoded.

19. The method of claim 1 , wherein the converting comprises generating the visual media data file in accordance with the visual media data.

20. The method of claim 1 , wherein the converting comprises parsing the visual media file to obtain the visual media data.

21. 1. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions, comprising:

21. An apparatus, the instructions, when executed by the processor, causing the processor to perform the method of any one of claims 1 to 20.

22. A non-transitory computer-readable medium having a computer program product for use by the video coding apparatus, comprising: A non-transitory computer-readable medium, the computer program product having computer-executable instructions stored on the non-transitory computer-readable medium that, when executed by the processor, causes the video coding apparatus to perform the method of any one of claims 1 to 20.

Images