EDRAP in DASH based on ARI track

Abstract

A mechanism for processing video data is disclosed. An indication in an addressable resource index (ARI) track configuration box in an ARI track is determined. The ARI track indexes a common media application format (CMAF) switching set. The indication indicates whether an extended dependent random access point (EDRAP) sample is allowed to be present in one or more tracks of a CMAF handover set. A transition is performed between the media data and the media data file based on the indication.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 367,306, filed on June 29, 2022. The entire contents of all of the above patent applications are hereby incorporated by reference. Technical Field

[0003] This patent document relates to the generation, storage and use of digital audio and video media information in file format. Background Art

[0004] Digital video consumes the largest amount of bandwidth used on the Internet and other digital communications networks. As the number of networked user devices capable of receiving and displaying video increases, bandwidth demands for digital video usage are likely to continue to grow. Summary of the invention

[0005] A first aspect relates to a method for processing video data, comprising: determining an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and wherein the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to be present in one or more tracks of the CMAF switch set; and performing conversion between media data and a media data file based on the indication.

[0006] A second aspect relates to a non-transitory computer-readable recording medium storing a bitstream of a video generated by a method performed by a video processing device, wherein the method includes: determining an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switching set, and wherein the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to exist in one or more tracks of the CMAF switching set; and generating a bitstream based on the determination.

[0007] A third aspect relates to an apparatus for processing video data, comprising: a processor; and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform any of the above aspects.

[0008] A fourth aspect relates to a non-transitory computer-readable medium comprising a computer program product for use by a video codec device, the computer program product comprising computer executable instructions stored on the non-transitory computer-readable medium, so that when executed by a processor, the video codec device performs the method of any of the above aspects.

[0009] A fifth aspect relates to a method for storing a bitstream of a video, comprising: determining an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and wherein the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to be present in one or more tracks of the CMAF switch set; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.

[0010] For the sake of clarity, any of the foregoing embodiments may be combined with any of the other foregoing embodiments to form new embodiments within the scope of the present disclosure.

[0011] These and other features will become more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] For a more complete understanding of the present disclosure, reference is now made to the following brief description taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0013] Figure 1 is a diagram illustrating an example mechanism for random access when decoding a bitstream using intra random access point (IRAP) pictures.

[0014] Figure 2 is a diagram of an example mechanism for random access when decoding a bitstream using dependent random access point (IRAP) pictures.

[0015] Figure 3 is a diagram of an example mechanism for random access when decoding a bitstream using an EDRAP picture.

[0016] Figure 4 is a schematic diagram of an example mechanism for signaling an external bitstream to support EDRAP-based random access.

[0017] Figure 5 An example of EDRAP-based random access is shown.

[0018] Figure 6 A block diagram of an example video processing system is shown.

[0019] Figure 7 is a block diagram of an example video processing device.

[0020] Figure 8 is a flow chart of an example method of video processing.

[0021] Fig. 9 A block diagram of an example video codec system is shown.

[0022] Fig.10 A block diagram of an example encoder is shown.

[0023] Fig.11 A block diagram of an example decoder is shown.

[0024] Fig.12 is a schematic diagram of an example encoder. DETAILED DESCRIPTION

[0025] First, it should be understood that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods may be implemented using any number of techniques, whether currently known or yet to be developed. The present disclosure should in no way be limited to the illustrative implementations, diagrams, and techniques shown below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims and their full scope of equivalents.

[0026] The section headings used in this document are for ease of understanding and do not limit the applicability of the techniques and embodiments disclosed in each section to only that section. In addition, the use of H.266 terminology in certain descriptions is only for ease of understanding and is not intended to limit the scope of the disclosed technology. Therefore, the techniques described herein are also applicable to other video codec protocols and designs. In this document, editorial changes to the Versatile Video Codec (VVC) specification or the International Organization for Standardization (ISO)-based Media File Format (ISOBMFF) file format specification are in bold italics to indicate canceled text and in bold underline to indicate added text.

[0027] 1. Preliminary Discussion

[0028] This document relates to video streaming. Specifically, the disclosure relates to the design of DASH-based Extended Dependent Random Access Point (EDRAP)-based video streaming using Main Stream Representation (MSR) and External Stream Representation (ESR) and signaling of EDRAP attributes in Addressable Resource Index (ARI) tracks. These examples can be applied to media streaming systems, for example, based on the Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP) (DASH) standard or its extensions, and / or Common Media Application Format (CMAF), either alone or in various combinations.

[0029] 2. Video Codec Introduction

[0030] 2.1 Video Codec Standards

[0031] Video codec standards have evolved primarily through the development of standards by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) and the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC). ITU-T developed H.261 and H.263, ISO / IEC developed Moving Picture Experts Group (MPEG)-1 and MPEG-4 Visual, and the two organizations jointly developed H.262 / MPEG-2 Video, H.264 / MPEG-4 Advanced Video Codec (AVC), and H.265 / High Efficiency Video Codec (HEVC) [1]. Since H.262, video codec standards have been based on a hybrid video codec structure that uses temporal prediction plus transform coding. To explore future video codec technologies beyond HEVC, the Video Codec Experts Group (VCEG) and MPEG jointly established the Joint Video Exploration Team (JVET). JVET has adopted many methods and put them into a reference software called the Joint Exploration Model (JEM) [2]. When the Versatile Video Codec (VVC) project was officially launched, JVET was renamed the Joint Video Experts Team (JVET). VVC[3] is a codec standard that aims to reduce the bit rate by 50% compared to HEVC.

[0032] The Versatile Video Codec (VVC) standard (ITU-T H.266 | ISO / IEC 23090-3)[3][4] and the related Versatile Supplementary Enhancement Information (VSEI) standard (ITU-T H.274 | ISO / IEC 23002-7)[5][6] are designed for the widest possible range of applications, including traditional uses such as television broadcasting, video conferencing or playback from storage media, as well as newer and more advanced use cases such as adaptive bitrate streaming, video region extraction, content combination and merging of video bitstreams from multiple codecs, multi-view video, scalable layered codecs and viewport-adaptive 360° immersive media.

[0033] 2.2 Video Format Standards

[0034] Media streaming applications are based on Internet Protocol (IP), Transmission Control Protocol (TCP) and Hypertext Transfer Protocol (HTTP) transport methods and rely on file formats such as ISO Base Media File Format (ISOBMFF). One such streaming system is Dynamic Adaptive Streaming over HTTP (DASH). In order to use the video formats of ISOBMFF and DASH, file format specifications specific to the video format are required, such as the AVC file format and the HEVC file format in [9], to encapsulate the video content in ISOBMFF tracks and in DASH representations and segments. Important information about the video bitstream, such as profile, tier and level and many other information, needs to be exposed as file format level metadata and / or DASH Media Presentation Description (MPD) to enable content selection purposes, such as selecting suitable media segments for initialization at the start of a streaming session and for stream adaptation during a streaming session.

[0035] Likewise, in order to use the ISOBMFF image format, a file format specification specific to the image format is required, for example, the AVC image file format and the HEVC image file format in

[10] .

[0036] 2.3 DASH

[0037] In Dynamic Adaptive Streaming over HTTP (DASH), there may be multiple representations of video and / or audio data of multimedia content. Different representations may correspond to different codec characteristics (e.g., different profiles or levels of a video codec standard, different bit rates, different spatial resolutions, etc.). A list of these representations may be defined in a media presentation description (MPD) data structure. A media presentation may correspond to a structured set of data accessible to a DASH streaming client device. A DASH streaming client device may request and download media data information to present a streaming service to a user of the client device. A media presentation may be described in an MPD data structure, which may include updates to the MPD.

[0038] A media presentation may contain a sequence of one or more time periods. Each time period may extend until the next time period begins, or in the case of the last time period, until the media presentation ends. Each time period may contain one or more representations of the same media content. A representation may be one of a plurality of alternatively encoded versions of audio, video, timed text, or other such data. The representation may differ by encoding type, for example, the bit rate, resolution, and / or codec for video data, and the bit rate, language, and / or codec for audio data. The term "representation" may be used to refer to a portion of encoded audio or video data that corresponds to a particular time period of multimedia content and is encoded in a particular manner.

[0039] Representations for a particular time period may be assigned to a group indicated by an attribute in the MPD indicating the adaptation set to which these representations belong. Representations in the same adaptation set are generally considered to be alternatives to each other, i.e., a client device may dynamically and seamlessly switch between these representations in order to, for example, perform bandwidth adaptation. For example, each representation of video data for a particular time period may be assigned to the same adaptation set so that any representation may be selected for decoding to present media data, such as video data or audio data, of the multimedia content for the corresponding time period. In some examples, the media content within a time period may be represented by one representation from group 0 (if any), or by a combination of at most one representation from each non-zero group. Timing data for each representation of a time period may be presented relative to the start time of the time period.

[0040] The representation may include one or more fragments. Each representation may include an initialization fragment, or each fragment of the representation may be self-initializing. When present, the initialization fragment may contain initialization information for accessing the representation. Typically, the initialization fragment may not contain media data. A fragment may be uniquely referenced by an identifier, such as a uniform resource locator (URL), a uniform resource name (URN), or a uniform resource identifier (URI). The MPD may provide an identifier for each fragment. In some examples, the MPD may also provide a byte range in the form of a range attribute, which may correspond to the data of the fragment within a file accessible by the URL, URN, or URI.

[0041] Different representations can be selected to retrieve different types of media data in a substantially synchronized manner. For example, a client device can select an audio representation, a video representation, and a timed text representation from which to retrieve a segment. In some examples, a client device can select a specific adaptation set to perform bandwidth adaptation. For example, a client device can select an adaptation set including a video representation, an adaptation set including an audio representation, and / or an adaptation set including a timed text. In the example, the client device can select an adaptation set for certain types of media (e.g., video) and directly select a representation for other types of media (e.g., audio and / or timed text). The following steps illustrate an example DASH streaming process. The client obtains an MPD. The client estimates the downlink bandwidth and selects a video representation and an audio representation based on the estimated downlink bandwidth and codec, decoding capabilities, display size, audio language settings, etc. Unless the end of the media presentation is reached, the client requests a media segment of the selected representation and presents the streaming content to the user. The client continues to estimate the downlink bandwidth. When the bandwidth changes significantly in a certain direction (e.g., becomes lower), the client selects a different video representation to match the newly estimated bandwidth, and continues to download the media segment and display it as an updated representation.

[0042] 2.4 Random Access and Its Support in HEVC and VVC

[0043] Random access means accessing and decoding a bitstream starting 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 seeking in a stream, and stream adaptation in a stream, the bitstream includes frequent random access points. These access points can be intra-coded pictures, but can also be inter-coded pictures, for example, in case of gradual decoding refresh.

[0044] HEVC includes signaling of intra-frame random access point (IRAP) pictures in the NAL unit header via the NAL unit type. Three types of IRAP pictures are supported in HEVC, which are instant decoding refresh (IDR), clean random access (CRA), and broken link access (BLA) pictures. IDR pictures constrain the inter-picture prediction structure to not reference any pictures before the current group of pictures (GOP). The reference pictures in the current GOP can be called closed GOP random access points. CRA pictures have fewer restrictions, allowing certain pictures to reference pictures before the current GOP, all of which will be discarded in the case of random access. CRA pictures can be called open GOP random access points. BLA pictures typically originate from the splicing of two bitstreams or parts thereof at CRA pictures, for example, during stream switching. In order to better enable the system to use IRAP pictures, six different NAL units are defined to signal the properties of IRAP pictures. These attributes can be used to better match the stream access point types defined in ISOBMFF [7], which are used for random access support in Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) [8].

[0045] VVC supports three types of IRAP pictures, two types of IDR pictures (one type has an associated random access decodable preamble (RADL) picture and the other type does not), and one type of CRA picture. The use of these pictures is similar to that in HEVC. There are two reasons why the BLA picture type in HEVC is not included in VVC. First, the basic functionality of the BLA picture can be implemented by a CRA picture plus a sequence end NAL unit, the presence of which indicates that subsequent pictures start a new CVS in a single-layer bitstream. Second, during the development of VVC, it was hoped 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 in the NAL unit header.

[0046] Another difference in random access support between VVC and HEVC is that gradual decoding refresh (GDR) is supported in a more standardized way in VVC. In GDR, decoding of the bitstream can start from an inter-coded picture. At the beginning of access, the entire picture area cannot be correctly decoded. However, after a certain number of pictures, the entire picture area is correctly decoded. AVC and HEVC also support GDR, using the recovery point supplementary enhancement information (SEI) message to signal GDR random access points and recovery points. In VVC, the NAL unit type is specified to indicate a GDR picture, and the recovery point is signaled in the picture header syntax structure. Codec video sequences (CVS) and bitstreams are allowed to start with GDR pictures. This means that the entire bitstream is allowed to contain only inter-coded pictures without a single intra-coded picture. The main benefit of specifying GDR support in this way is to provide consistent behavior for GDR. GDR enables the encoder to smooth the bitrate of the bitstream by distributing intra-coded slices or blocks across multiple pictures instead of intra-coding the entire picture. This enables significantly lower end-to-end latency, which in many cases is considered more important than before as ultra-low latency applications such as wireless displays, online gaming, drone-based applications, etc. become more popular.

[0047] Another GDR-related feature in VVC is virtual boundary signaling. The boundary between the refresh area (i.e., the correctly decoded area) and the unrefreshed area at the picture between the GDR picture and the corresponding recovery point can be signaled as a virtual boundary. When signaled, cross-border loop filtering will not be applied. Therefore, decoding mismatches of some samples at or near the boundary will not occur. It can be useful when the application determines that the correctly decoded area is displayed during the GDR process. IRAP pictures and GDR pictures can be collectively referred to as random access point (RAP) pictures.

[0048] 2.5 Video Coding, Decoding, Storage, and Streaming Based on Extended Dependent Random Access Points (EDRAP)

[0049] 2.5.1 Concept and Standard Support

[0050] This section describes the concepts of video encoding, decoding, storage and streaming based on EDRAP.

[0051] like Figure 1As shown, the application (e.g., adaptive streaming) determines the frequency of random access points (RAPs), such as a RAP period of 1 second or 2 seconds. In one example, RAP is provided by encoding and decoding IRAP pictures. Note that inter-frame prediction references for non-critical pictures between RAP pictures are not shown, and the output order is from left to right. When randomly accessed from CRA4, the decoder receives and correctly decodes CRA4, CRA5, etc. and related inter-frame prediction pictures.

[0052] Figure 2 The DRAP method is shown, which improves codec efficiency by allowing DRAP pictures (and subsequent pictures) to reference previous IRAP pictures for inter-frame prediction. Note that inter-frame prediction of non-critical pictures between RAP pictures is not shown, and the output order is from left to right. When randomly accessed from DRAP4, the decoder receives and correctly decodes IDR0, DRAP4, DRAP5, etc. and related inter-frame predicted pictures.

[0053] Figure 3 The EDRAP method is shown, which brings more flexibility by allowing EDRAP pictures (and subsequent pictures) to reference a few earlier RAP pictures (IRAP or EDRAP). Note that inter-frame prediction of non-critical pictures between RAP pictures is not shown, and the output order is from left to right. When randomly accessed from EDRAP4, the decoder receives and correctly decodes IDR0, EDRAP2, EDRAP4, EDRAP5, etc. and related inter-frame predictions.

[0054] Figure 4 An example of the EDRAP method using the MSR fragment and the ESR fragment is shown. Figure 5 An example of random access from EDRAP4 is shown. When randomly accessing or switching from a segment starting at EDRAP4 to a segment of EDRAP4, the decoder receives and decodes segments including IDR0, EDRAP2, EDRAP4, EDRAP5, etc. and related inter-frame prediction pictures.

[0055] EDRAP-based video codecs are supported by the EDRAP indication SEI message in the VSEI standard amendment. The storage part is supported by the EDRAP sample group and associated external stream track references in the ISOBMFF standard amendment. The stream part is supported by the main stream representation (MSR) and external stream representation (ESR) descriptors included in the DASH standard amendment. These examples are described below.

[0056] 2.5.2 EDRAP Streams in DASH

[0057] An example implementation of DASH includes the specification of the Main Stream Representation (MSR) and External Stream Representation (ESR) descriptors as follows:

[0058] Change 1: EDRAP Stream

[0059] In clause 2, add the following reference: ISO / IEC 1449612:2021 AMD1, Information technology — Codecs of audiovisual objects — Part 12: ISO base media file format, AMD 1 improved branding document and other improvements

[0060] In subclause 3.2, add the following abbreviations: Extended Dependent Random Access Point (EDRAP), External Stream Representation (ESR), and Main Stream Representation (MSR).

[0061] Add subclause 5.8.5.15 as follows:

[0062] 5.8.5.15 MSR and ESR Descriptors

[0063] 5.8.5.15.1 General

[0064] An adaptation set may have an EssentialProperty descriptor with @schemeIdUri equal to urn:mpeg:dash:msr:2022. This descriptor is called an MSR descriptor. This descriptor may only be present in the adaptation set level, and its presence indicates that each representation in this adaptation set is an MSR that carries a video track containing a track reference of type "aest".

[0065] An adaptation set may have an EssentialProperty descriptor with @schemeIdUri equal to urn:mpeg:dash:esr:2022. This descriptor is called an ESR descriptor. This descriptor may only be present in the adaptation set level, and its presence indicates that each representation in the adaptation set is an ESR that carries a video track containing a track reference of type "aest". An ESR is intended to be used or played only with its associated MSR.

[0066] Each ESR shall be associated with an MSR via the representation level attributes @associationId and @associationType in the MSR as follows: The @id of the associated ESR shall be represented by the value contained in the attribute @associationId for which the corresponding value in the attribute @associationType is equal to "aest". Each MSR shall have an associated ESR.

[0067] For the interrelated MSR and ESR, the following applies:

[0068] For each media sample with a specific presentation time in the ESR, there should be a corresponding media sample with the same presentation time in the MSR. Each media sample in the MSR with a corresponding ESR media sample is called an EDRAP sample. The first byte position of each EDRAP sample in the MSR should be the index of the start access unit (ISAU) of the sequence access point (SAP), which enables the media stream in the MSR to be played, provided that the corresponding ESR media sample is provided to the media decoder immediately before the EDRAP sample. Each EDRAP sample in the MSR should be the first sample in a segment or sub-segment (for example, each EDRAP sample should start a segment or sub-segment). For each segment or sub-segment in the MSR that starts with an EDRAP sample, there should be a segment in the ESR with the same earliest presentation time as the MSR segment or sub-segment. This segment in the ESR is called the corresponding ESR segment of the MSR segment or sub-segment, and vice versa. The concatenation of any segment in the ESR with the corresponding MSR segment or subsegment (e.g., an MSR segment or subsegment with the same earliest presentation time as the ESR segment) and all subsequent MSR segments or subsegments will produce a consistent bitstream. For each MSR segment or subsegment that does not start with an EDRAP sample, there should not be a corresponding ESR segment with the same earliest presentation time as the MSR segment or subsegment.

[0069] 5.8.5.15.2 Example Content Preparation and Client Operation (Informative)

[0070] The following are examples of content preparation and client operations based on MSRs and their associated ESRs. Examples of content preparation operations are as follows. Video content is encoded into one or more representations, each with a specific spatial resolution, temporal resolution, and quality. Each representation of the video content is represented by a pair of associated MSRs and ESRs. The MSRs of the video content are included in one adaptation set. The ESRs of the video content are included in another adaptation set.

[0071] An example of client operation is as follows. The client obtains the MPD for media presentation, parses the MPD, and selects an MSR. When initializing a session or performing a search, the client determines the starting presentation time at which the content will be used, and requests a segment or sub-segment of the MSR, specifically starting with a segment or sub-segment that starts with SAP and contains a sample whose presentation time is equal to (or earlier than but close enough to) the determined starting presentation time. For each sub-segment in the requested segment, a segment index is requested in advance to obtain information about each sub-segment, and a partial HTTP GET request is used. If there is a segment in the associated ESR whose earliest presentation time is the same as the starting MSR segment or sub-segment, the ESR segment will also be requested, preferably before the request for the starting MSR segment or sub-segment. Otherwise, the segment of the associated ESR is not requested. When switching to a different MSR, the client requests segments or sub-segments of the switched MSR, specifically starting with the first segment or sub-segment whose earliest presentation time is greater than the earliest presentation time of the last requested segment or sub-segment of the MSR before the switch. If there is a fragment in the associated ESR whose earliest presentation time is the same as the starting fragment or sub-fragment in the switched MSR, then that ESR fragment is also requested, preferably before the request of the starting fragment or sub-fragment in the switched MSR. Otherwise, the fragment of the associated ESR is not requested. When subsequent fragments or sub-fragments of an MSR are requested and used continuously after session initialization, seeking, or stream switching, there is no need to request fragments of the associated ESR, including when requesting any subsequent MSR fragments or sub-fragments that start with an EDRAP sample.

[0072] As can be seen from the example client operation above, the client should calculate the earliest presentation time of the MSR fragment and sub-fragment as well as the ESR fragment, so as to clarify whether the MSR fragment or sub-fragment has an associated ESR fragment.

[0073] 2.6 Addressable Resource Index (ARI) Track in DASH

[0074] The example DASH implementation specifies the ARI track as shown below.

[0075] Annex X

[0076] Addressable Resource Index Track

[0077] A.1 Advanced Solutions

[0078] The following aspects are observed. In some cases, it is necessary for the adaptive streaming client to know exactly the duration and size of the addressable resources and possibly a subset of these resources on the server. The addressable resources are track files, fragments or chunks in the context of CMAF, but the same applies to DASH or HTTP Live (HLS). For on-demand services, the fragment index can provide an accurate mapping of this information.

[0079] However, there are cases where additional information about the segment information can be beneficial for client and network operation, and for which the segment index is not sufficient. Examples include: A solution is needed for different operation modes: low latency live, live, time-shifted, video on demand (VoD). The solution is expected to be applicable to different target latencies for clients. Clients and network addresses operate under different network conditions. The message also includes information about the quality of the content. Note: Although this track uses CMAF terminology, this can also be applied to DASH adaptation sets that are not CMAF compliant.

[0080] The Addressable Resource Index (ARI) track provides a solution to the above example by describing all the details of the addressable resources and subsets of a CMAF switch set in the metadata track. The ARI track is applied to a CMAF switch set where each CMAF track has the same segment, fragment, and chunk structure in terms of duration.

[0081] The following principles apply. ARI tracks are time-aligned with CMAF switch sets. ARI tracks record properties of several or all tracks of a CMAF switch set. Header information is defined for metadata tracks. A sample of an ARI track is associated with each CMAF chunk. A sample contains details of the time-aligned CMAF chunks in several or all CMAF tracks of a CMAF switch set. Each sample of an ARI track is a synchronization sample. The delivery and segmentation of tracks is independent of the chunk / fragment structure of the associated switch set.

[0082] A.2 Definition: CMAF Addressable Resource Index

[0083] A.2.1 Definition

[0084] Sample entry type: 'cari'

[0085] Container: Sample description box ('stsd')

[0086] Mandatory: No

[0087] Quantity: 0 or 1

[0088] This metadata describes all details of the addressable resources and subsets of the CMAF switch set in the metadata track. It is assumed that the same fragment, fragment and chunk structure applies for several or all tracks in the CMAF switch set. In addition, each CMAF track can be uniquely identified by track_id.

[0089] The following principles apply. The ARI track is time-aligned with the tracks of the CMAF switch set. The ARI track records the properties of all tracks of the CMAF switch set. Header information is defined for the metadata track. Samples of the track are defined for each CMAF chunk in a time-aligned manner. The association of chunks with metadata samples is done so that the baseMediaDecodeTime of the chunk is the same as the sample time in the metadata track. The samples contain detailed information about the chunks in each track in the switch set. Note that this track can even be used to carry, for example, Event or Producer Reference times for media presentations.

[0090] A.2.2 Syntax

[0091] The CMAF addressable resource index metadata uses the following sample entry:

[0092] class CmafAriMetaDataSampleEntry()

[0093] extends MetaDataSampleEntry('cari'){

[0094] CmafAriConfigurationBox();

[0095] }

[0096] aligned(8)class CmafAriConfigurationBox

[0097] extends FullBox('cari',version=0,flags=0){

[0098] unsigned int(32)switching_set_identifier;

[0099] unsigned int(16)num_tracks;

[0100] unsigned int(16)num_quality_indicators;

[0101] for(i=1;i<=num_tracks;i++){

[0102] unsigned int(32)track_id;

[0103] / / provides the order of the tracks for each sample

[0104] }

[0105] / / additional information on the CMAF Switching Set may be providedfor(i=1;i<=num_quality_indicators;i++){

[0106] string quality_identifier;

[0107] }

[0108] }

[0109] The CMAF addressable resource index sample uses the following syntax: class CmafAriFormatStruct(){

[0110] for(i=1;i<=num_tracks;i++){

[0111] / / this information may also be provided per track

[0112] unsigned int(1) segment_start_flag;

[0113] unsigned int(1) marker;

[0114] unsigned int(3) SAP_type;

[0115] unsigned int(1) emsg_flag;

[0116] unsigned int(1) prft_flag;

[0117] bit(25)reserved;

[0118] unsigned int(32)offset

[0119] unsigned int(32)size;

[0120] for(i=1;i<=num_quality_indicators;i++){

[0121] unsigned int(32) quality;

[0122] }

[0123] unsigned int(1) loss;

[0124] bit(15) reserved;

[0125] unsigned int(8) num_prediction_pairs;

[0126] for(i = 1; i <= num_prediction_pairs; i++){

[0127] unsigned int(32) prediction_min_window;

[0128] unsigned int(32) predicted_max_bitrate;

[0129] }

[0130] A.2.3 Semantics

[0131] The switching_set_identifier specifies a unique identifier for a switching set in the application context. num_tracks indicates the number of tracks indexed in the ARI track. track_ID provides selection and ordering in samples of a track using track_ID. num_quality_indicators specifies the number of quality indicators used to identify the quality of a chunk. quality_identifier specifies an identifier that describes how the quality values ​​in a sample are expected to be interpreted. This is a four-character code (4CC) code that can be registered. segment_start_flag indicates whether the chunk is the start of a segment. marker identifies whether this chunk includes at least one styp box. SAP_type identifies the SAP type of the chunk. emsg_flag indicates whether this chunk provides at least one emsg box. prft_flag indicates whether this chunk includes at least one prft box. offset identifies the offset of the chunk from the start of the segment. size provides the size of the chunk in octets. quality provides the quality of the chunk according to a given quality scheme identifier. The data type (integer or floating point) of the quality value is defined by the quality scheme. If the quality scheme identifier is the empty string, then quality is an unsigned integer interpreted linearly with increasing quality values. loss indicates media data loss for the chunk. num_prediction_pairs provides how many pairs of expected predictions are provided. prediction_min_windows provides a value for minbuffertime that is identical to the MDP value. predicted_max_bitrate provides a value for bandwidth that is identical to the MDP semantics, which remains constant for the duration of the prediction_min_windows value.

[0132] 3. Technical problems solved by public technical solutions

[0133] The example design of the EDRAP-based stream and the design of the ARI track have the following problems. In the configuration box of the ARI track that signals the information of the CMAF switch set, it is desired to signal whether the EDRAP sample can exist in one or more tracks of the CMAF switch set indexed in the ARI track. From the example client operation in the EDRAP stream in DASH, it can be seen that the client should calculate the earliest presentation time of the MSR fragments and sub-fragments and the ESR fragments to determine whether the MSR fragment or sub-fragment has an associated ESR fragment. It is desired to signal whether the MSR fragments and sub-fragments have associated ESR fragments, thereby eliminating the need to calculate the information by calculating the earliest presentation time of the MSR fragments and sub-fragments and the ESR fragments.

[0134] 4. List of solutions and implementation examples

[0135] In order to solve the above problems, the following summarized methods are disclosed. Each example should be regarded as an example to explain the general concept and should not be interpreted in a narrow way. In addition, these examples can be applied individually or combined in any way.

[0136] Example 1

[0137] In one example, to address the first issue, it is signaled in the ARI track configuration box whether EDRAP samples may be present in one or more tracks of the CMAF switch set indexed in the ARI track.

[0138] Example 2

[0139] In one example, to address the second issue, it is signaled whether an MSR segment or sub-segment has an associated ESR segment. In one example, whether an MSR segment or sub-segment has an associated ESR segment is signaled by an indication of the index track in the samples of the ARI track. The indication indicates whether the SAP from which the block in the index track starts is an EDRAP. It should be noted that if the index track has an EDRAP sample, the index track is an MSR. In the presence of other constraints on the EDRAP samples in the MSR, the indication of whether the SAP from which the block in the index track starts is an EDRAP indicates whether the MSR segment or sub-segment has an associated ESR segment. In another example, whether an MSR segment or sub-segment has an associated ESR segment is signaled in the MDP.

[0140] 5. Examples

[0141] The following are some example embodiments of some of the disclosures summarized above in Section 4. Most of the relevant parts that have been added or modified are shown in bold, while some deleted parts are shown in italic bold. There may be some other changes that are editorial in nature and are therefore not highlighted.

[0142] 5.1 First Embodiment

[0143] This embodiment is directed to items 1 and 2 above.

[0144] Annex X

[0145] Addressable Resource Index Track

[0146] A.1 Advanced Solutions

[0147] The following aspects are observed. In some cases, it is necessary for the adaptive streaming client to know exactly the duration and size of the addressable resources and possibly a subset of these resources on the server. The addressable resources are track files, fragments or chunks in the context of CMAF, but the same applies to DASH or HTTP Live (HLS). For on-demand services, the fragment index can provide an accurate mapping of this information.

[0148] However, there are cases where additional information about the segment information can be beneficial for client and network operations, for which the segment index is not sufficient. Examples include: A solution is needed for different operation modes: low latency live, live, time-shifted, VoD. The solution is expected to be applicable to different target latencies for clients. Clients and network addresses operate under different network conditions. The message also includes information about the quality of the content. Please note: Although this track uses CMAF terminology, this can also be applied to DASH adaptation sets that are not CMAF compliant.

[0149] The Addressable Resource Index (ARI) track provides a solution for the above use case by describing all the details of the addressable resources and subsets of a CMAF switch set in the metadata track. The ARI track is applied to a CMAF switch set where each CMAF track has the same segment, fragment, and chunk structure in terms of duration.

[0150] The following principles apply. ARI tracks are time-aligned with CMAF switch sets. ARI tracks record properties of several or all tracks of a CMAF switch set. Header information is defined for metadata tracks. A sample of an ARI track is associated with each CMAF chunk. A sample contains details of the time-aligned CMAF chunks in several or all CMAF tracks of a CMAF switch set. Each sample of an ARI track is a synchronization sample. The delivery and segmentation of tracks is independent of the chunk / fragment structure of the associated switch set.

[0151] A.2 Definition: CMAF Addressable Resource Index

[0152] A.2.1 Definition

[0153] Sample entry type: 'cari'

[0154] Container: Sample description box ('stsd')

[0155] Mandatory: No

[0156] Quantity: 0 or 1

[0157] This metadata describes all details of the addressable resources and subsets of the CMAF switch set in the metadata track. It is assumed that the same fragment, fragment and block structure applies to several or all tracks in the CMAF switch set. In addition, each CMAF track can be uniquely identified by track_id.

[0158] The following principles apply. The ARI track is time-aligned with the tracks of the CMAF switch set. The ARI track records the properties of all tracks of the CMAF switch set. Header information is defined for the metadata track. Samples of the track are defined for each CMAF chunk in a time-aligned manner. The association of chunks with metadata samples is done so that the baseMediaDecodeTime of the chunk is the same as the sample time in the metadata track. The samples contain detailed information about the chunks in each track in the switch set. Note that this track can even be used to carry, for example, Event or Producer Reference times for media presentations.

[0159] A.2.2 Syntax

[0160] The CMAF addressable resource index metadata uses the following sample entry:

[0161] class CmafAriMetaDataSampleEntry()

[0162] extends MetaDataSampleEntry('cari'){

[0163] CmafAriConfigurationBox();

[0164] }

[0165] aligned(8)class CmafAriConfigurationBox

[0166] extends FullBox('cari',version=0,flags=0){

[0167] unsigned int(32)switching_set_identifier;

[0168] unsigned int(16 10)num_tracks;

[0169] unsigned int(16 10)num_quality_indicators;

[0170] unsigned int(1) edrap_allowed_flag;

[0171] bit(11) reserved;

[0172] for(i = 1; i <= num_tracks; i++){

[0173] unsigned int(32) track_id;

[0174] / / provides the order of the tracks for each sample

[0175] }

[0176] / / additional information on the CMAF Switching Set may be provided

[0177] for(i = 1; i <= num_quality_indicators; i++){

[0178] string quality_identifier;

[0179] }

[0180] }

[0181] The CMAF addressable resource index sample uses the following syntax:

[0182] class CmafAriFormatStruct(){

[0183] for(i = 1; i <= num_tracks; i++){

[0184] / / this information may also be provided per track

[0185] unsigned int(1) segment_start_flag;

[0186] unsigned int(1) marker;

[0187] unsigned int(3) SAP_type;

[0188] unsigned int(1) emsg_flag;

[0189] unsigned int(1) prft_flag;

[0190] unsigned int(1) sap_is_edrap_flag;

[0191] bit(25 24)reserved;

[0192] unsigned int(32)offset

[0193] unsigned int(32)size;

[0194] for(i=1;i<=num_quality_indicators;i++){

[0195] unsigned int(32)quality;

[0196] }

[0197] unsigned int(1)loss;

[0198] bit(15)reserved;

[0199] unsigned int(8)num_prediction_pairs;

[0200] for(i=1;i<=num_prediction_pairs;i++){

[0201] unsigned int(32)prediction_min_window;

[0202] unsigned int(32)predicted_max_bitrate;

[0203] }

[0204] }

[0205] A.2.3 Semantics

[0206] switching_set_identifier specifies the unique identifier of the switching set in the application context. num_tracks indicates the number of tracks indexed in the ARI track. num_quality_indicators specifies the number of quality indicators used to identify the quality of the block.

[0207] edrap_allowed_flag specifies whether Extended Dependent Random Access Point (EDRAP) samples may be present in one or more tracks indexed in the ARI track. An EDRAP sample is a sample that can be correctly decoded among all subsequent samples in the same track in decoding and output order, provided that the most recent preceding SAP sample of type 1, 2, or 3 and zero or more preceding EDRAP samples are available when decoding this sample and subsequent samples.

[0208] track_ID provides selection and ordering among samples of a track using track_ID. quality_identifier specifies an identifier that describes how the quality values ​​in a sample are expected to be interpreted. This is a 4CC code that can be registered. segment_start_flag indicates whether the chunk is the start of a segment. marker identifies whether this chunk includes at least one stypbox.

[0209] SAP_type, when greater than 0, identifies the SAP type of the SAP from which this block starts. emsg_flag indicates whether this block provides at least one emsg box (event message box). prft_flag indicates whether this block includes at least one prft box (producer reference time box).

[0210] sap_is_edrap_flag indicates whether the SAP from which this block starts is an EDRAP. When edrap_allowed_flag is equal to 0, the value of sap_is_edrap_flag shall be equal to 0.

[0211] offset identifies the offset of the chunk from the start of the fragment. size provides the size of the chunk in octets. quality provides the quality of the chunk according to the given quality scheme identifier. The data type of the quality value (integer or floating point) is defined by the quality scheme. If the quality scheme identifier is the empty string, then quality is an unsigned integer and the quality value increases linearly as the value increases. loss indicates that media data for the chunk has been lost. num_prediction_pairs provides how many pairs of expected predictions are provided. prediction_min_windows provides a value for minbuffer time that is identical to the MDP value. predicted_max_bitrate provides a value for bandwidth that is identical to the MDP semantics and remains constant for the duration of the prediction_min_windows value. ...

[0213] 7. References

[0214] [1]ITU-T and ISO / IEC,“High efficiency video coding”,Rec.ITU-T H.265|ISO / IEC 23008-2(in force edition).

[0215] [2]J.Chen,E.Alshina,G.J.Sullivan,J.-R.Ohm,J.Boyce,“Algorithmdescription of Joint Exploration Test Model 7(JEM7),”JVET-G1001,Aug.2017.

[0216] [3]Rec.ITU-T H.266|ISO / IEC 23090-3,“Versatile Video Coding”,2020.

[0217] [4]B.Bross,J.Chen,S.Liu,Y.-K.Wang(editors),“Versatile Video Coding(Draft 10),” JVET-S2001 .

[0218] [5]Rec.ITU-T Rec.H.274|ISO / IEC 23002-7,“Versatile SupplementalEnhancement Information Messages for Coded Video Bitstreams”,2020.

[0219] [6]J.Boyce,V.Drugeon,G.J.Sullivan,Y.-K.Wang(editors),“Versatilesupplemental enhancement information messages for coded video bitstreams(Draft 5),”JVET-S2007.

[0220] [7]ISO / IEC 14496-12:"Information technology—Coding of audio-visualobjects—Part 12:ISO base media file format".

[0221] [8]ISO / IEC 23009-1:"Information technology—Dynamic adaptivestreaming over HTTP(DASH)—Part 1:Media presentation description and segmentformats".

[0222] [9]ISO / IEC 14496-15:"Information technology—Coding of audio-visualobjects—Part 15:Carriage of network abstraction layer(NAL)unit structuredvideo in the ISO base media file format".

[0223]

[10] ISO / IEC 23008-12:"Information technology—High efficiency codingand media delivery in heterogeneous environments—Part 12:Image File Format".

[0224]

[11] J.Boyce,G.J.Sullivan,Y.-K.Wang(editors),“Additional SEI messagesfor VSEI(Draft 6),”JVET-Y2006.

[0225]

[12] ISO / IEC JTC 1 / SC 29 / WG 03output document N0550,"PotentialImprovements of Text of CDAM ISO / IEC 14496-12:2021AMD 1Improved branddocumentation and other improvements",Apr.2022.

[0226]

[13] ISO / IEC JTC 1 / SC 29 / WG 03output document N0559, "WD of ISO / IEC23009-15th edition AMD 2EDRAP streaming and other extensions",Apr.2022.

[0227]

[14] ISO / IEC JTC 1 / SC 29 / WG 03output document N0541, "PotentialImprovements of ISO / IEC 23009-1 4th edition DAM 2PrePeriod, nonlinear playback and other extensions",Apr.2022.

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

[0229] System 4000 may include a codec component 4004, which may implement various codecs or encoding methods described in this document. Codec component 4004 may reduce the average bit rate of the video from input 4002 to the output of codec component 4004 to generate a codec representation of the video. Therefore, codec technology is sometimes referred to as video compression or video transcoding technology. The output of codec component 4004 may be stored or transmitted via a connected communication, as represented by component 4006. The stored or transmitted bitstream (or codec) representation of the video received at input 4002 may be used by component 4008 to generate pixel values ​​or displayable video sent to display interface 4010. The process of generating a video that a user can watch from a bitstream representation is sometimes referred to as video decompression. In addition, although some video processing operations are referred to as "codec" operations or tools, it will be understood that codec tools or operations are used at the encoder, and the corresponding decoding tools or operations of the inverse codec results will be performed by the decoder.

[0230] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI) or Display Port, etc. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect (PCI), Integrated Drive Electronics (IDE) interface, etc. The techniques described in this document may be embodied in various electronic devices, such as mobile phones, laptop computers, smart phones, or other devices capable of performing digital data processing and / or video display.

[0231] Figure 7 4106 is a block diagram of an example video processing device 4100. Device 4100 may be used to implement one or more methods described herein. Device 4100 may be embodied in a smart phone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. Device 4100 may include one or more processors 4102, one or more memories 4104, and video processing circuitry 4106. Processor 4102 may be configured to implement one or more methods described in this document. (Multiple) memories 4104 may be used to store data and code for implementing the methods and techniques described herein. Video processing circuitry 4106 may be used to implement some of the techniques described in this document in hardware circuitry. In some embodiments, video processing circuitry 4106 may be at least partially included in processor 4102, such as a graphics coprocessor.

[0232] Figure 8 4200. The method 4200 determines, in step 4202, an indication in an ARI track configuration box in an ARI track. The ARI track indexes a CMAF switch set. The indication indicates whether EDRAP samples are allowed to be present in one or more tracks of the CMAF switch set. In step 4204, based on the indication, a conversion between media data and a media data file is performed. The conversion may include encoding at an encoder, decoding at a decoder, or a combination thereof.

[0233] It should be noted that the method 4200 may be implemented in an apparatus for processing video data, the apparatus comprising a processor and a non-transitory memory having instructions thereon, such as the video encoder 4400, the video decoder 4500, and / or the encoder 4600. In this case, the instructions, when executed by the processor, cause the processor to perform the method 4200. In addition, the method 4200 may be performed by a non-transitory computer-readable medium including a computer program product for use by a video codec device. The computer program product includes computer executable instructions stored on a non-transitory computer-readable medium, such that when executed by the processor, the video codec device performs the method 4200.

[0234] Fig. 943 is a block diagram illustrating an example video codec system 4300 that can utilize the techniques of the present disclosure. The video codec system 4300 can include a source device 4310 and a destination device 4320. The source device 4310 generates encoded video data, which can be referred to as a video encoding device. The destination device 4320 can decode the encoded video data generated by the source device 4310, which can be referred to as a video decoding device.

[0235] Source device 4310 may include a video source 4312, a video encoder 4314, and an input / output (I / O) interface 4316. Video source 4312 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 video data, or a combination of these sources. Video data may include one or more pictures. Video encoder 4314 encodes video data from video source 4312 to generate a bit stream. The bit stream may include a bit sequence forming a codec representation of video data. The bit stream may include a coded picture and associated data. The coded picture is a coded representation of a picture. Associated data may include a sequence parameter set, a picture parameter set, and other syntax structures. I / O interface 4316 may include a modulator / demodulator (modem) and / or a transmitter. Encoded video data may be directly transmitted to destination device 4320 via network 4330 via I / O interface 4316. Encoded video data may also be stored on storage medium / server 4340 for access by destination device 4320.

[0236] Destination device 4320 may include an I / O interface 4326, a video decoder 4324, and a display device 4322. I / O interface 4326 may include a receiver and / or a modem. I / O interface 4326 may obtain encoded video data from source device 4310 or storage medium / server 4340. Video decoder 4324 may decode the encoded video data. Display device 4322 may display the decoded video data to a user. Display device 4322 may be integrated with destination device 4320, or may be external to destination device 4320, which is configured to interface with an external display device.

[0237] The video encoder 4314 and the video decoder 4324 may operate according to a video compression standard, such as the High Efficiency Video Codec (HEVC) standard, the Versatile Video Codec (VVM) standard, and other current and / or future standards.

[0238] Fig.10 is a block diagram showing an example of a video encoder 4400, which may be Fig. 94300. Video encoder 4400 may be configured to perform any or all of the techniques of the present disclosure. Video encoder 4400 includes multiple functional components. The techniques described in the present disclosure may be shared between various components of video encoder 4400. In some examples, the processor may be configured to perform any or all of the techniques described in the present disclosure.

[0239] The functional components of the video encoder 4400 may include a segmentation unit 4401, a prediction unit 4402 (which may include a mode selection unit 4403, a motion estimation unit 4404, a motion compensation unit 4405 and an intra-frame prediction unit 4406), a residual generation unit 4407, a transform processing unit 4408, a quantization unit 4409, an inverse quantization unit 4410, an inverse transform unit 4411, a reconstruction unit 4412, a buffer 4413 and an entropy coding unit 4414.

[0240] In other examples, the video encoder 4400 may include more, fewer, or different functional components. In one example, the prediction unit 4402 may include an intra-block copy (IBC) unit. The IBC unit may perform prediction in an IBC mode in which at least one reference picture is a picture in which the current video block is located.

[0241] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205 , may be highly integrated but are represented separately in the example of the video encoder 4400 for purposes of explanation.

[0242] The segmentation unit 4401 may segment the picture into one or more video blocks. The video encoder 4400 and the video decoder 4500 may support various video block sizes.

[0243] The mode selection unit 4403 may select one of the intra or inter coding modes, for example based on the error result, and provide the resulting intra or inter coded block to the residual generation unit 4407 to generate residual block data, and to the reconstruction unit 4412 to reconstruct the coded block for use as a reference picture. In some examples, the mode selection unit 4403 may select a combined intra and inter prediction (CIIP) mode, where the prediction is based on an inter prediction signal and an intra prediction signal. The mode selection unit 4403 may also select a resolution (e.g., sub-pixel or integer pixel precision) of the motion vector of the block in the case of inter prediction.

[0244] To perform inter-frame prediction on the current video block, the motion estimation unit 4404 may generate motion information of the current video block by comparing the current video block with one or more reference frames from the buffer 4413. The motion compensation unit 4405 may determine a predicted video block of the current video block based on the motion information of pictures other than the picture associated with the current video block from the buffer 4413 and decoded samples.

[0245] The motion estimation unit 4404 and the motion compensation unit 4405 may perform different operations for the current video block, eg, depending on whether the current video block is in an I slice, a P slice, or a B slice.

[0246] In some examples, the motion estimation unit 4404 may perform unidirectional prediction on the current video block, and the motion estimation unit 4404 may search for a reference video block of the current video block in the reference pictures of list 0 or list 1. The motion estimation unit 4404 may then generate a reference index indicating a reference picture containing the reference video block in list 0 or list 1 and a motion vector indicating a spatial displacement between the current video block and the reference video block. The motion estimation unit 4404 may output the reference index, the prediction direction indicator, and the motion vector as motion information of the current video block. The motion compensation unit 4405 may generate a predicted video block of the current block based on the reference video block indicated by the motion information of the current video block.

[0247] In other examples, the motion estimation unit 4404 may perform bidirectional prediction on the current video block, and the motion estimation unit 4404 may search for a reference video block of the current video block in the reference pictures in list 0, and may also search for another reference video block of the current video block in the reference pictures in list 1. The motion estimation unit 4404 may then generate a reference index indicating the reference pictures in list 0 and list 1 containing the reference video block and a motion vector indicating a spatial displacement between the reference video block and the current video block. The motion estimation unit 4404 may output the reference index and the motion vector of the current video block as the motion information of the current video block. The motion compensation unit 4405 may generate a predicted video block of the current video block based on the reference video block indicated by the motion information of the current video block.

[0248] In some examples, motion estimation unit 4404 may output the entire set of motion information for use in a decoding process by a decoder. In some examples, motion estimation unit 4404 may not output the entire set of motion information for the current video. Instead, motion estimation unit 4404 may signal the motion information of the current video block with reference to the motion information of another video block. For example, motion estimation unit 4404 may determine that the motion information of the current video block is sufficiently similar to the motion information of a neighboring video block.

[0249] In one example, the motion estimation unit 4404 may indicate a value in a syntax structure associated with the current video block that indicates to the video decoder 4500 that the current video block has the same motion information as another video block.

[0250] In another example, the motion estimation unit 4404 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 is used to indicate the difference between the motion vector of the current video block and the motion vector of the indicated video block. The video decoder 4500 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0251] As described above, the video encoder 4400 can predictively signal motion vectors. Examples of two predictive signaling techniques that the video encoder 4400 can implement include Advanced Motion Vector Prediction (AMVP) and merge mode signaling.

[0252] The intra prediction unit 4406 may perform intra prediction on the current video block. When the intra prediction unit 4406 performs intra prediction on the current video block, the intra prediction unit 4406 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.

[0253] The residual generation unit 4407 may generate residual data of the current video block by subtracting the predicted video block of the current video block from the current video block. The residual data of the current video block may include residual video blocks corresponding to different sample components of samples in the current video block.

[0254] In other examples, there may be no residual data for the current video block, such as in skip mode, and the residual generation unit 4407 may not perform a subtraction operation.

[0255] The transform processing unit 4408 may generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to the residual video block associated with the current video block.

[0256] After the transform processing unit 4408 generates a transform coefficient video block associated with the current video block, the quantization unit 4409 may quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values ​​associated with the current video block.

[0257] The inverse quantization unit 4410 and the inverse transform unit 4411 may apply inverse quantization and inverse transform to the transform coefficient video block, respectively, to reconstruct a residual video block from the transform coefficient video block. The reconstruction unit 4412 may add the reconstructed residual video block to the corresponding samples of one or more prediction video blocks generated by the prediction unit 4402 to generate a reconstructed video block associated with the current block for storage in the buffer 4413.

[0258] After the reconstruction unit 4412 reconstructs the video block, a loop filtering operation may be performed to reduce video block artifacts in the video block.

[0259] The entropy coding unit 4414 may receive data from other functional components of the video encoder 4400. When the entropy coding unit 4414 receives data, the entropy coding unit 4414 may perform one or more entropy coding operations to generate entropy-coded data and output a bitstream including the entropy-coded data.

[0260] Fig.11 A block diagram showing an example of a video decoder 4500, which may be Fig. 9 4300. The video decoder 4500 may be configured to perform any or all of the techniques of the present disclosure. In the example shown, the video decoder 4500 includes multiple functional components. The techniques described in the present disclosure may be shared between various components of the video decoder 4500. In some examples, the processor may be configured to perform any or all of the techniques described in the present disclosure.

[0261] In the example shown, the video decoder 4500 includes an entropy decoding unit 4501, a motion compensation unit 4502, an intra-frame prediction unit 4503, an inverse quantization unit 4504, an inverse transform unit 4505, a reconstruction unit 4506, and a buffer 4507. In some examples, the video decoder 4500 may perform a decoding process that is substantially the inverse of the encoding process described in conjunction with the video encoder 4400.

[0262] The entropy decoding unit 4501 may retrieve an encoded bitstream. The encoded bitstream may include entropy-encoded video data (e.g., encoded video data blocks). The entropy decoding unit 4501 may decode the entropy-encoded video data, and the motion compensation unit 4502 may determine motion information including motion vectors, motion vector precision, reference picture list indexes, and other motion information from the entropy-decoded video data. For example, the motion compensation unit 4502 may determine this information by performing AMVP and merge mode.

[0263] The motion compensation unit 4502 may generate a motion compensated block, possibly performing interpolation based on an interpolation filter. An identifier of an interpolation filter used with sub-pixel precision may be included in a syntax element.

[0264] The motion compensation unit 4502 may calculate interpolation of sub-integer pixels of a reference block using an interpolation filter as used by the video encoder 4400 during encoding of the video block. The motion compensation unit 4502 may determine the interpolation filter used by the video encoder 4400 from received syntax information and use the filter to produce a predictive block.

[0265] The motion compensation unit 4502 can use some syntax information to determine the size of blocks used to encode frames and / or slices of the encoded video sequence, partition information describing how each macroblock of the pictures of the encoded video sequence is partitioned, a mode indicating how to encode each partition, one or more reference frames (and reference frame lists) for each inter-frame coded block, and other information used to decode the encoded video sequence.

[0266] The intra prediction unit 4503 may form a prediction block from spatially neighboring blocks using, for example, an intra prediction mode received in the bitstream. The inverse quantization unit 4504 inversely quantizes (i.e., dequantizes) the quantized video block coefficients provided in the bitstream and decoded by the entropy decoding unit 4501. The inverse transform unit 4505 applies an inverse transform.

[0267] The reconstruction unit 4506 may sum the residual block with the corresponding prediction block generated by the motion compensation unit 4502 or the intra prediction unit 4503 to form a decoded block. If necessary, a deblocking filter may also be applied to filter the decoded block to remove blocking artifacts. The decoded video block is then stored in a buffer 4507, which provides reference blocks for subsequent motion compensation / intra prediction and also generates decoded video for presentation on a display device.

[0268] Fig.12 4600 is a schematic diagram of an example encoder 4600. Encoder 4600 is suitable for implementing VVC technology. Encoder 4600 includes three loop filters, namely deblocking filter (DF) 4602, sample adaptive offset (SAO) 4604 and adaptive loop filter (ALF) 4606. Unlike DF 4602, which uses predefined filters, SAO 4604 and ALF 4606 use the original samples of the current picture to reduce the mean square error between the original samples and the reconstructed samples by adding an offset and applying a finite impulse response (FIR) filter, respectively, with the help of codec side information of signaling offsets and filter coefficients. ALF 4606 is located at the last processing stage of each picture and can be regarded as a tool that attempts to capture and repair artifacts produced by previous stages.

[0269] The encoder 4600 also includes an intra prediction component 4608 and a motion estimation / compensation (ME / MC) component 4610 configured to receive an input video. The intra prediction component 4608 is configured to perform intra prediction, while the ME / MC component 4610 is configured to perform inter prediction using a reference picture obtained from a reference picture buffer 4612. The residual block from the inter prediction or intra prediction is fed to a transform (T) component 4614 and a quantization (Q) component 4616 to generate a quantized residual transform coefficient, which is fed to an entropy coding component 4618. The entropy coding component 4618 entropy codes and decodes the prediction result and the quantized transform coefficient and sends it to a video decoder (not shown). The quantized component output from the quantization component 4616 can be fed to an inverse quantization component 4620, an inverse transform component 4622, and a reconstruction (REC) component 4624. The REC component 4624 is capable of outputting images to the DF 4602 , SAO 4604 , and ALF 4606 for filtering before the images are stored in the reference picture buffer 4612 .

[0270] A list of some example preferred solutions is provided next.

[0271] The following solutions illustrate examples of the techniques discussed herein.

[0272] The following solution illustrates an example embodiment of the techniques discussed in the previous section (eg, item 1).

[0273] 1. A method for processing media data, comprising: determining (4202) an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to be present in one or more tracks of the CMAF switch set; and performing (4204) conversion between media data and a media data file based on the indication.

[0274] The following solution illustrates an example implementation of the techniques discussed in the previous section (eg, item 2).

[0275] 2. A method for processing video data, comprising: determining an indication indicating whether a main stream representation (MSR) segment or an MSR sub-segment is associated with an external stream representation (ESR) segment; and performing conversion between media data and a media data file based on the indication.

[0276] 3. A method according to any of solutions 1 to 2, wherein the indication is included in an indication of an index track in samples of the ARI track.

[0277] 4. The method according to any one of solutions 1 to 3, wherein the indication indicates whether a sequence access point (SAP) at the beginning of the block in the index track is an EDRAP.

[0278] 5. A method according to any one of solutions 1 to 4, wherein when the index track contains EDRAP samples, the index track contains MSR.

[0279] 6. A method according to any one of solutions 1 to 5, wherein the indication is in an Addressable Resource Index (ARI) track.

[0280] 7. A method according to any one of solutions 1 to 5, wherein the indication is in a Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) Media Presentation Description (MPD).

[0281] 8. An apparatus for processing video data, comprising: a processor; and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform a method according to any one of solutions 1 to 7.

[0282] 9. A non-transitory computer-readable medium comprising a computer program product for use by a video codec device, the computer program product comprising computer executable instructions stored on the non-transitory computer-readable medium, so that when executed by a processor, the video codec device performs a method according to any one of solutions 1 to 7.

[0283] 10. A non-transitory computer-readable recording medium storing a bitstream of a video generated by a method executed by a video processing device, wherein the method comprises: determining an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to exist in one or more tracks of the CMAF switch set; and generating a bitstream based on the determination.

[0284] 11. A method for storing a bitstream of a video, comprising: determining an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to be present in one or more tracks of the CMAF switch set; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.

[0285] 12. A method, apparatus or system described in this document.

[0286] The additional solutions illustrate examples of the techniques discussed herein.

[0287] 1. A method for processing media data, comprising: determining an indication in an ARI track configuration box in an Addressable Resource Index (ARI) track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch, and wherein the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to be present in one or more tracks of the CMAF switch set; and performing conversion between media data and a media data file based on the indication.

[0288] 2. The method of solution 1, wherein the indication is an EDRAP allowed flag (edrap_allowed_flag), and wherein edrap_allowed_flag specifies whether EDRAP samples may be present in one or more tracks indexed in the ARI track.

[0289] 3. A method according to any of solutions 1 to 2, wherein an EDRAP sample is a sample that can be correctly decoded among all subsequent samples in the same track in decoding and output order, provided that when decoding the sample and subsequent samples, the nearest previous sequence access point (SAP) sample of type 1, 2 or 3 and zero or more previous EDRAP samples are available.

[0290] 4. The method according to any one of solutions 1 to 3, wherein edrap_allowed_flag is included in the CMAF addressable resource index metadata.

[0291] 5. The method according to any one of solutions 1 to 4, wherein the ARI track includes a SAP is EDRAP flag (sap_is_edrap_flag) indicating whether the SAP from which the block starts is EDRAP.

[0292] 6. The method according to any one of solutions 1 to 5, wherein when edrap_allowed_flag is equal to 0, the value of sap_is_edrap_flag shall be equal to 0.

[0293] 7. The method according to any one of solutions 1 to 6, wherein sap_is_edrap_flag is included in the CMAF addressable resource index sample.

[0294] 8. The method according to any of solutions 1 to 7, wherein the ARI track comprises a SAP type (SAP_type), and wherein SAP_type, when greater than 0, identifies the SAP type of the SAP with which the block starts.

[0295] 9. A method according to any one of solutions 1 to 8, wherein SAP_type is included in the CMAF addressable resource index sample.

[0296] 10. A method according to any one of solutions 1 to 9, wherein the conversion comprises generating a media data file from the media data.

[0297] 11. A method according to any one of solutions 1 to 9, wherein the conversion includes parsing the media data from a media data file.

[0298] 12. A non-transitory computer-readable recording medium storing a bitstream of a video generated by a method executed by a video processing device, wherein the method comprises: determining an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and wherein the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to exist in one or more tracks of the CMAF switch set; and generating a bitstream based on the determination.

[0299] 13. The non-transitory computer readable recording medium of solution 12, wherein the indication is an EDRAP allowed flag (edrap_allowed_flag), and wherein edrap_allowed_flag specifies whether EDRAP samples may be present in one or more tracks indexed in the ARI track.

[0300] 14. A non-transitory computer-readable recording medium according to any one of solutions 12 to 13, wherein an EDRAP sample is a sample that can be correctly decoded among all subsequent samples in the same track in decoding and output order, provided that when decoding the sample and subsequent samples, the most recent previous sequence access point (SAP) sample of type 1, 2 or 3 and zero or more previous EDRAP samples are available.

[0301] 15. The non-transitory computer-readable recording medium according to any one of solutions 12 to 14, wherein edrap_allowed_flag is included in the CMAF addressable resource index metadata.

[0302] 16. The non-transitory computer-readable recording medium according to any one of solutions 12 to 15, wherein the ARI track includes a SAP is EDRAP flag (sap_is_edrap_flag) indicating whether the SAP from which the block starts is EDRAP.

[0303] 17. The non-transitory computer-readable recording medium according to any one of solutions 12 to 16, wherein when edrap_allowed_flag is equal to 0, the value of sap_is_edrap_flag shall be equal to 0.

[0304] 18. The non-transitory computer-readable recording medium according to any one of solutions 12 to 17, wherein sap_is_edrap_flag is included in the CMAF addressable resource index sample.

[0305] 19. The non-transitory computer-readable recording medium according to any one of solutions 12 to 18, wherein the ARI track includes a SAP type (SAP_type), and wherein SAP_type, when greater than 0, identifies the SAP type of the SAP with which the block starts.

[0306] 20. The non-transitory computer-readable recording medium according to any one of solutions 12 to 19, wherein SAP_type is included in a CMAF addressable resource index sample.

[0307] 21. A device for processing video data, comprising: at least one processor; and a non-volatile memory having instructions thereon, wherein the instructions, when executed by the at least one processor, cause the at least one processor to perform a method according to any one of solutions 1 to 11.

[0308] 22. A non-transitory computer-readable medium comprising a computer program product for use by a video codec device, the computer program product comprising computer executable instructions stored on the non-transitory computer-readable medium, so that when executed by a processor, the video codec device performs a method according to any one of solutions 1 to 11.

[0309] 23. A method for storing a bitstream of a video, comprising: determining an indication in an Addressable Resource Index (ARI) track configuration box in an ARI track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and wherein the indication indicates whether an Extended Dependent Random Access Point (EDRAP) sample is allowed to be present in one or more tracks of the CMAF switch set; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.

[0310] In the solution described herein, an encoder can comply with the format rules by generating a codec representation according to the format rules. In the solution described herein, a decoder can parse syntax elements in the codec representation using the format rules, while being aware of the presence and absence of syntax elements according to the format rules to produce decoded video.

[0311] In this document, 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 the conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. For example, the bitstream representation of a current video block may correspond to bits that are co-located or dispersed in different places within the bitstream, as defined by syntax. For example, a macroblock may be encoded based on error residual values ​​from a transform and codec, and may also be encoded using bits in headers and other fields in the bitstream. In addition, during conversion, the decoder may parse the bitstream based on the determination knowing that some fields may or may not be present, as described in the above solution. Similarly, the encoder may determine whether certain syntax fields are included, and generate the encoded representation accordingly by including or excluding the syntax fields from the encoded representation.

[0312] The disclosed and other solutions, examples, embodiments, modules and functional operations described in this document may be implemented in digital electronic circuits or in computer software, firmware or hardware (including the structures disclosed in this document and the equivalents of their structures), or a combination of one or more of them. 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, which are used to be executed by a data processing device or control the operation of the data processing device. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a combination of substances that affect machine-readable propagable signals, or a combination of one or more of them. The term "data processing device" covers all devices, equipment and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device may include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagation signal is an artificially generated signal, for example, a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device.

[0313] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language (including compiled or interpreted languages), and 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 stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborative files (e.g., files storing one or more modules, subroutines, or code portions). A computer program may be deployed to execute on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0314] The processes and logic flows described in this document can 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. These processes and logic flows can also be performed by special purpose logic circuitry, and the apparatus can be implemented as special purpose logic circuitry, for example, an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0315] Processors suitable for the execution of computer programs include, for example, both general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic, magneto-optical disks, or optical disks) for storing data, or be operably coupled to receive data from or transfer data to, or receive data from and transfer data to, the one or more mass storage devices (e.g., magnetic, magneto-optical disks, or optical disks). However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and memory devices, including, for example, semiconductor memory devices (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and compact disk read-only memory (CD ROM) and digital versatile disk read-only memory (DVD-ROM) disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0316] Although this patent document contains many details, these details should not be interpreted as limitations on the scope of any subject matter or content that can be claimed, but as descriptions of features that can be specific to a particular embodiment of a particular technology. In this patent document, certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments, respectively, or in various suitable sub-combinations. In addition, although the features may be described as working in certain combinations and even initially required in the same manner as described above, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0317] Similarly, although operations are depicted in a particular order in the drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in the sequential order shown, or that all illustrated operations be performed, in order to achieve the desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0318] Only a few implementations and examples are described, and other implementations, enhancements, and variations may be made based on what is described and shown in this patent document.

[0319] A first component is directly coupled to a second component when there is no intermediate component between the first component and the second component other than a line, trace, or other medium. A first component is indirectly coupled to a second component when there is an intermediate component between the first component and the second component other than a line, trace, or other medium. The term "coupled" and its synonyms include direct coupling and indirect coupling. Unless otherwise specified, the term "approximately" means a range of ±10% of the number that follows it.

[0320] Although several embodiments have been provided in the present disclosure, it will be appreciated that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit and scope of the present disclosure. The present examples are to be considered illustrative rather than restrictive, and the intention is not to be limited to the details given herein. For example, various elements or components may be combined or integrated in another system, or certain features may be omitted or not implemented.

[0321] In addition, the techniques, systems, subsystems, and methods described and shown as discrete or separate in various embodiments may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled may be directly connected or indirectly coupled or communicated through an interface, device, or intermediate component (whether electrically, mechanically, or otherwise). Other examples of changes, substitutions, and modifications may be made by those skilled in the art and may be made without departing from the spirit and scope of the present disclosure.

Claims

1. A method for processing media data, comprising: determining an indication in an ARI track configuration box in an Addressable Resource Index (ARI) track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and the indication indicates whether Extended Dependent Random Access Point (EDRAP) samples are allowed to be present in one or more tracks of the CMAF switch set; and Conversion between the media data and the media data file is performed based on the indication.

2. The method according to claim 1, wherein: The indication is an EDRAP allowed flag (edrap_allowed_flag), and the edrap_allowed_flag specifies whether EDRAP samples are present in one or more tracks indexed in the ARI track.

3. The method according to any one of claims 1 to 2, wherein: An EDRAP sample is a sample that can be correctly decoded among all subsequent samples in the same track in decoding and output order, provided that when decoding the EDRAP sample and subsequent samples, the nearest preceding sequence access point (SAP) sample of type 1, 2, or 3 and zero or more preceding EDRAP samples are available.

4. The method according to any one of claims 1 to 3, wherein: The CMAF addressable resource index metadata includes the edrap_allowed_flag.

5. The method according to any one of claims 1 to 4, wherein: The ARI track includes a SAP is EDRAP flag (sap_is_edrap_flag), which indicates whether a SAP block starts with EDRAP.

6. The method according to any one of claims 1 to 5, wherein: When edrap_allowed_flag is equal to 0, the value of sap_is_edrap_flag is equal to 0.

7. The method according to any one of claims 1 to 6, wherein: The CMAF addressable resource index sample includes the sap_is_edrap_flag.

8. The method according to any one of claims 1 to 7, wherein: The ARI track includes a SAP type (SAP_type), which, when greater than 0, identifies the SAP type of the SAP with which a block starts.

9. The method according to any one of claims 1 to 8, wherein: The CMAF addressable resource index sample includes the SAP_type.

10. The method according to any one of claims 1 to 9, wherein: The converting includes generating the media data file from the media data.

11. The method according to any one of claims 1 to 9, wherein: The converting includes parsing the media data from the media data file.

12. A non-transitory computer-readable recording medium storing a bit stream of a video generated by a method performed by a video processing device, wherein: The method comprises: determining an indication in an ARI track configuration box in an Addressable Resource Index (ARI) track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and the indication indicates whether Extended Dependent Random Access Point (EDRAP) samples are allowed to be present in one or more tracks of the CMAF switch set; and A bitstream is generated based on the determination.

13. The non-transitory computer-readable recording medium according to claim 12, wherein: The indication is an EDRAP allowed flag (edrap_allowed_flag), which specifies whether EDRAP samples are present in one or more tracks indexed in the ARI track.

14. The non-transitory computer-readable recording medium according to any one of claims 12 to 13, wherein: An EDRAP sample is a sample that can be correctly decoded among all subsequent samples in the same track in decoding and output order, provided that when decoding the EDRAP sample and subsequent samples, the nearest preceding sequence access point (SAP) sample of type 1, 2, or 3 and zero or more preceding EDRAP samples are available.

15. The non-transitory computer-readable recording medium according to any one of claims 12 to 14, wherein: The CMAF addressable resource index metadata includes the edrap_allowed_flag.

16. The non-transitory computer-readable recording medium according to any one of claims 12 to 15, wherein: The ARI track includes a SAP is EDRAP flag (sap_is_edrap_flag), which indicates whether a SAP block starts with EDRAP.

17. The non-transitory computer-readable recording medium according to any one of claims 12 to 16, wherein: When edrap_allowed_flag is equal to 0, the value of sap_is_edrap_flag is equal to 0.

18. The non-transitory computer-readable recording medium according to any one of claims 12 to 17, wherein: The CMAF addressable resource index sample includes the SAP type.

19. The non-transitory computer-readable recording medium according to any one of claims 12 to 18, wherein: The ARI track includes a SAP type (SAP_type), which, when greater than 0, identifies the SAP type of the SAP with which a block starts.

20. The non-transitory computer-readable recording medium according to any one of claims 12 to 19, wherein: The CMAF addressable resource index sample includes the SAP_type.

21. A device for processing video data, comprising: at least one processor; and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 11.

22. A non-transitory computer-readable medium comprising: A computer program product for use in a video codec device, wherein the computer program product comprises computer executable instructions stored on the non-transitory computer readable medium, so that when the computer executable instructions are executed by a processor, the video codec device performs the method according to any one of claims 1 to 11.

23. A method for storing a bit stream of a video, comprising: determining an indication in an ARI track configuration box in an Addressable Resource Index (ARI) track, wherein the ARI track indexes a Common Media Application Format (CMAF) switch set, and the indication indicates whether Extended Dependent Random Access Point (EDRAP) samples are allowed to be present in one or more tracks of the CMAF switch set; generating a bitstream based on the determination; and The bit stream is stored in a non-transitory computer-readable recording medium.

Images