ES2633651T3 - Coding of parameter sets and NAL unit headers for video coding - Google Patents

Abstract

A method of encoding video data, the method comprising: encoding (104, 122) a video parameter set, VPS, for a plurality of layers of video data, wherein each of the plurality of layers of video data refers to the VPS, and wherein the encoding of the VPS comprises: encoding of VPS data indicative of a number of frames to be reordered in at least one of the plurality of video data layers, encoding of VPS data VPS indicative of a certain number of pictures to be stored in a decoded picture buffer, DPB, during decoding of the plurality of video data layers, and encoding of VPS data indicative of a maximum number of temporal layers in the plurality of video data layers; and encoding (114, 130) the plurality of video data layers based, at least in part, on the VPS.

Description

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

DESCRIPTION

Coding of parameter sets and NAL unit headers for video coding TECHNICAL FIELD

This disclosure refers to video encoding.

BACKGROUND

Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, direct digital broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptops or desktops, tablet computers, e-book readers , digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cell phones or satellite radio, the so-called "smart phones", videoconferencing devices, video transmission devices and the like. Digital video devices implement video coding techniques, such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Encoding (AVC), the High Efficiency Video Encoding (HEVC) standard, currently under development and extensions of such standards. A recent draft of the next HEVC standard is available at
http: //phenix.int-

evry.fr/jct/doc_end_user/documents/7_Geneva/wg11/JCTVC-G1103-v3.zip. Video devices can transmit, receive, encode, decode and / or store digital video information more efficiently, implementing such video coding techniques.

Video coding techniques include spatial prediction (intra-image) and / or temporal prediction (between images) to reduce or eliminate intrinsic redundancy in video sequences. For block-based video coding, a video fragment (for example, a video frame or a part of a video frame) can be divided into video blocks, which can also be referred to as wooded blocks, encoding units (CU) and / or coding nodes. The video blocks in an intracoded fragment (I) of an image are encoded using spatial prediction with respect to reference samples in adjacent blocks of the same image. Video blocks in an intercoded fragment (P or B) of an image can use spatial prediction with respect to reference samples in contiguous blocks of the same image, or temporal prediction with respect to reference samples in other reference images . The images can be called frames and the reference images can be called reference frames.

Spatial or temporal prediction results in a predictive block for a block to be encoded. Residual data represents pixel differences between the original block to be encoded and the predictive block. An intercoded block is encoded according to a motion vector that points to a block of reference samples that form the predictive block, and residual data indicating the difference between the encoded block and the predictive block. An intracoded block is encoded according to an intracoding modality and residual data. For greater compression, residual data can be transformed from the pixel domain to a transformation domain, resulting in residual transformation coefficients, which can then be quantified. The quantized transformation coefficients, initially arranged in a two-dimensional formation, can be explored in order to produce a one-dimensional vector of transformation coefficients, and entropy coding can be applied to achieve even more compression. US 2005/0254575 A1 describes the production of one or more layers of the scalable data flow. The layers are characterized by an coding property and the procedure includes signaling the layers with the coding property so that they are readable by a decoder to determine the coding property without analyzing the scalable data flow. It also describes a scalable bit stream, in which at least two layers of scalability are present, and each layer is characterized by a set of at least one property, such as profile, level and a set of at least one HRD / VBV parameter, which may be different from that of the entire flow, and in which said set of at least one property is marked for at least one layer that is different from the entire flow. Jill Boyce et al., "Extensible High Layer Syntax for Scalability," JCTVC-E279, dated March 22, 2011, discloses using a set of DPS dependency parameters in addition to the set of SPS sequence parameters. In the DPS the same parameters are transmitted for multiple layers and in the SPS parameters are transmitted that are valid only for a specific layer. The invention is defined in the attached claim, to which reference should be made at this point.

SUMMARY

In general, this disclosure describes techniques for encoding sets of parameters and network abstraction layer units (NAL) for video coding. These techniques can be applied to single-layer encoded data, such as two-dimensional video data, as well as scalable video encoding (SVC) video data and multivist video encoding (MVC) video data. In this way, the parameter sets and NAL units can be mutually compatible between various types of video data. For example, a

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Video encoder, such as a video encoder or video decoder, can encode a set of video parameters (VPS) that defines parameters for a plurality of layers of video data. The layers may correspond, for example, to SVC layers (which have various frame rates, spatial resolutions and / or quality levels) and / or MVC data views (for example, image sequences of a scene captured from various perspectives of camera on a horizontal axis).

In one example, a video data encoding procedure includes encoding a set of video parameters (VPS) for a plurality of video data layers, in which each of the plurality of video data layers refers to the VPS and encode a plurality of video data layers based at least in part on the VPS, and in which the VPS encoding comprises:

VPS data coding indicative of a maximum number of time layers in the plurality of video data layers.

In other examples, a device corresponding to the above procedure and a computer readable storage medium is provided which has been stored in the instructions which, when executed, perform the above procedure.

The details of one or more examples are set forth in the accompanying drawings and in the following description. Other features, objects and advantages will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example video coding and decoding system that can use techniques to encode sets of parameters and network abstraction layer units (NAL) for one or more layers of video data

FIG. 2 is a block diagram illustrating an example of video encoder 20 that can implement the coding techniques of NAL parameter sets and units for one or more layers of video data.

FIG. 3 is a block diagram illustrating an example of video decoder 30 that can implement techniques for encoding sets of parameters and NAL units for one or more layers of video data.

FIG. 4 is a conceptual diagram illustrating an example MVC prediction pattern.

FIG. 5 is a conceptual diagram illustrating a set of video parameters (VPS) and several sets of layer parameters (LPS).

FIG. 6 is a conceptual diagram illustrating an example of a set of grouping parameters (GPS) and GPS relationships with other sets of parameters and fragment headers.

FIG. 7 is a flow chart illustrating an example of a video data encoding procedure according to the techniques of this disclosure.

FIG. 8 is a flow chart illustrating an example of a video data decoding procedure according to the techniques of this disclosure.

FIG. 9 is a flow chart illustrating an example of a video data encoding procedure based, at least in part, on a certain number of time layers as indicated in a VPS.

FIG. 10 is a flow chart illustrating an example of a video data coding procedure based, at least in part, on a certain number of images to be rearranged in one or more layers and images to be stored in a buffer of decoded images.

FIG. 11 is a flow chart illustrating an example of a video data encoding procedure based, at least in part, on hypothetical reference decoder (HRD) parameters set in a VPS.

FIG. 12 is a flowchart illustrating an example of a video data encoding procedure based, at least in part, on expansion data signaled in a VPS.

DETAILED DESCRIPTION

In general, this disclosure describes the encoding of video data using a set of video parameters

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

(VPS) Video data can be classified hierarchically as including a plurality of layers, a sequence of images within a given layer, an image within a sequence, fragments within an image and blocks (for example, macroblocks or coding tree units) within a fragment Sequence parameter sets (SPS) can be used to signal the changing parameters infrequently for an image sequence, and image parameter sets (PPS) can be used to signal the changing parameters infrequently of the individual images.

In accordance with the techniques of this disclosure, a VPS can signal the changing parameters infrequently for a plurality of sequences across the respective layers. That is, a VPS can include parameters for a set of temporarily co-located sequences of different layers. Different layers may include, for example, different views for multivist video data, different quality layers, different spatial resolution layers, temporarily scalable layers (i.e. layers that allow different frame rates) and the like. In this way, a VPS can be provided for a plurality of different layers, so that the VPS indicates the parameters that are common to each of the respective layers (for example, respective sequences within the respective layers). It can be said that a bit stream includes each of the plurality of layers, and the respective layers can form secondary streams of respective bits. In addition, a secondary bit stream may correspond to a combination of two or more layers.

This disclosure describes several examples of data that can be included in a VPS. Such data may include, in some examples, an indication of a certain number of sub-layers (for example, a maximum number of sub-layers) within the corresponding layers. For example, a VPS may include data that indicates a certain number of time layers and / or a maximum number of time layers (for example, a higher time layer identifier).

To mention another example, a VPS may include, additionally or alternatively, data substantially similar to any data previously signaled in an SPS (ie, signaled in conventional SPS). Thus, when the sequences of two or more layers of a bit stream include substantially similar or identical parameters, a video encoder can encode a VPS to signal parameters for the sequences of the layers, instead of redundantly encoding said data in Respective SPS for the various sequences between the different layers.

A VPS may, additionally or alternatively, include data defining video usability information (VUI), such as video representation information, hypothetical reference decoder parameters (HRD) and / or bit flow restriction information . The bit stream restriction information may include restrictions on the range of the motion vector, the size of the decoded image buffer (DPB) (for example, in terms of a certain number of images to be maintained in the DPB) , the number of rearrangement frames (that is, an indication of a certain number of frames to be rearranged from the decoding order to the display order), coded block sizes (e.g., macroblocks (MBs) or coding tree units ) and encoded sizes of images. A VPS can provide additional data for one or more extensions of the VPS, so that the VPS can be extended by future standards or extensions of the next HEVC standard.

FIG. 1 is a block diagram illustrating an example video coding and decoding system 10 that can use techniques to encode sets of parameters and network abstraction layer units (NAL) for one or more layers of video data. As shown in FIG. 1, the system 10 includes a source device 12 that provides encoded video data, to be decoded at a later time by a destination device 14. In particular, the source device 12 provides the video data to the destination device 14 through a computer-readable medium 16. The source device 12 and the destination device 14 may comprise any of a wide range of devices, including desktop computers, folding computers (i.e., laptops), tablet computers, decoders, telephone equipment. such as the so-called "smart" phones, the so-called "smart" panels, televisions, cameras, display devices, digital media players, video game consoles, a video transmission device or the like. In some cases, the source device 12 and the destination device 14 may be equipped for wireless communication.

The destination device 14 can receive the encoded video data to be decoded by the computer-readable medium 16. The computer-readable medium 16 can comprise any type of media or device capable of moving the encoded video data from the device source 12 to the destination device 14. In one example, the computer-readable medium 16 may comprise a communication means to allow the source device 12 to transmit encoded video data directly to the destination device 14 in real time. The encoded video data may be modulated in accordance with a communication standard, such as a wireless communication protocol, and transmitted to the destination device 14. The communication medium may comprise any wireless or wired communication means, such as a spectrum radio frequency (RF) or one or more physical transmission lines. The communication medium may be part of a packet-based network, such as a local area network, a wide area network or a global network such as the Internet. The communication medium may include routers, switches, base stations or any other equipment that may be useful to facilitate the

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

communication from source device 12 to destination device 14.

In some examples, encoded data may be output from the output interface 22 to a storage device. Similarly, the encoded data of the storage device can be accessed through an input interface. The storage device may include any one of a variety of data storage, distributed or local access media, such as a rigid disk drive, Blu-ray discs, DVD discs, CD-ROM discs, flash memory, volatile memory or non volatile, or any other suitable means of digital storage, for storing encoded video data. In a further example, the storage device may correspond to a file server or other intermediate storage device that can store the encoded video data generated by the source device 12. The destination device 14 can access stored video data of the storage device, by flow or discharge. The file server can be any type of server capable of storing encoded video data and transmitting that encoded video data to the destination device 14. The exemplary file servers include an Internet server (for example, for a headquarters on the Network), an FTP server, network connected storage devices (NAS) or a local disk controller. The destination device 14 can access the encoded video data through any standard data connection, including an Internet connection. This may include a wireless channel (for example, a Wi-Fi connection), a cable connection (for example, DSL, cable modem, etc.), or a combination of both that is suitable for accessing video data encoded, stored on a file server. The transmission of encoded video data from the storage device may be a stream transmission, a download transmission or a combination of both.

The techniques of this disclosure are not necessarily limited to wireless applications or configurations. The techniques can be applied to video coding, in support of any of a variety of multimedia applications, such as television broadcasts over the air, cable television transmissions, satellite television transmissions, Internet video streams , such as dynamic adaptive flow over HTTP (DASH), digital video that is encoded in a data storage medium, digital video decoding stored in a data storage medium, or other applications. In some examples, the system 10 can be configured to support unidirectional or bidirectional video transmission, to support applications such as video transmission, video playback, video broadcasting and / or videotelephony.

In the example of FIG. 1, the source device 12 includes a video source 18, a video encoder 20 and an output interface 22. The destination device 14 includes an input interface 28, a video decoder 30 and a display device 32. According to this disclosure, the video encoder 20 of the source device 12 may be configured to apply entropy coding techniques sets of NAL parameters and units for one or more layers of video data. In other examples, a source device and a destination device may include other components or arrangements. For example, the source device 12 can receive video data from an external video source 18 as an external camera. Also, the destination device 14 can interact with an external display device, instead of including an integrated display device.

The illustrated system 10 of Figure 1 is simply an example. The techniques for encoding sets of NAL parameters and units for one or more layers of video data can be performed by any digital video encoding and / or decoding device. Although, in general, the techniques of this disclosure are carried out by means of a video encoding device, the techniques can also be carried out by means of a video encoder / decoder, typically called "CODEC". In addition, the techniques of this disclosure can also be carried out by a video preprocessor. The source device 12 and the destination device 14 are simply examples of such coding devices, where the source device 12 generates encoded video data for transmission to the destination device 14. In some examples, the devices 12, 14 may function as essentially symmetrical manner, so that each of the devices 12, 14 includes coding and video decoding components. Therefore, the system 10 can support a unidirectional or bidirectional video transmission between video devices 12, 14, for example, for video transmission, video playback, video broadcasting or video telephony.

The video source 18 of the source device 12 may include a video capture device, such as a video camera, a video file containing previously recorded video and / or a video feed interface for receiving video from a content provider Of video. As an additional alternative, video source 18 can generate data based on computer graphics such as source video, or a combination of live video, archived video and computer generated video. In some cases, if the video source 18 is a camcorder, the source device 12 and the destination device 14 can form the so-called camera phones or video telephones. However, as mentioned above, the techniques described in this disclosure may be applicable to video coding in general, and may be applied to wireless and / or wired applications. In each case, the recorded, prerecorded or computer generated video can be encoded by the video encoder 20. The encoded video information can then be output by the output interface 22 in a computer-readable medium 16.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

The computer-readable medium 16 may include transient means, such as a wireless broadcast or a wired network transmission, or storage media (i.e. non-transient storage media), such as a hard disk, a flash memory drive, a compact disc, a digital video disc, a Blu-ray disc or other computer-readable media. In some examples, a network server (not shown) can receive encoded video data from the source device 12 and provide the encoded video data to the destination device 14, for example, by network transmission. Similarly, an information device of a media production facility, such as a disc burning facility, can receive encoded video data from the source device 12 and produce a disc containing the encoded video data. Therefore, it can be understood that the computer-readable medium 16 includes one or more computer-readable media in several ways, in several examples.

The input interface 28 of the destination device 14 receives information from the computer-readable medium 16. The information of the computer-readable medium 16 may include syntactic information defined by the video encoder 20, which is also used by the video decoder 30 , which includes syntactic elements that describe features and / or the processing of blocks and other encoded units, for example, groups of images (GOP). The display device 32 shows the decoded video data to a user and can comprise any of a variety of display devices, such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma screen , a light emitting organic diode (OLED) screen or other display device.

The video encoder 20 and the video decoder 30 can operate in accordance with a video compression standard, such as the high-efficiency video encoding standard (HEVC), currently under development, and can be adjusted to the model of HEVC test (HM). Alternatively, video encoder 20 and video decoder 30 can operate in accordance with other private or industrial standards, such as ITU-T H.264, also called MPEG -4, Part 10, advanced video encoding (AVC) or extensions of these standards. However, the techniques of this disclosure are not limited to any particular coding standard. Other examples of video coding standards include MPEG-2 and ITU-T H.263. Although not shown in FIG. 1, in some aspects, the video encoder 20 and the video decoder 30 may each be integrated with an audio encoder and decoder, and may include suitable multiplexing and demultiplexing units, or other hardware and software, to manage coding, both audio and video, in a common data stream or in different data streams. If applicable, the multiplexing and demultiplexing units can conform to the ITU H.223 multiplexing protocol or other protocols, such as the user datagram protocol (UDP).

The ITU-T H.264 / MPEG-4 (AVC) standard was formulated by the ITU-T Video Encoding Group of Experts (VCEG), together with the ISO / IEC Group of Experts on Pellets, as the product of a collective association known as the Joint Video Team (JVT). In some aspects, the techniques described in this disclosure can be applied to devices that generally conform to the H.264 standard. The H.264 standard is described in ITU-T Recommendation H.264, Advanced Video Coding, for generic audiovisual services, by the ITU-T Study Group, dated March 2005, and which can be denominate in this document standard H.264 or descriptive memory H.264, or the standard or descriptive memory H.264 / AVC. The Joint Video Team (JVT) continues to work on extensions for H.264 / MPEG-4 AVC.

The video encoder 20 and the video decoder 30 can be implemented as any one of a variety of suitable encoder circuits, such as one or more microprocessors, digital signal processors (DSP), specific application integrated circuits (ASICs), data matrixes On-site programmable doors (FPGA), discrete logic, software, hardware, firmware or any combination of these. When the techniques are partially implemented in software, a device may store instructions for the software in suitable non-transient computer readable media, and execute the instructions in hardware by one or more processors performing the techniques of this disclosure. Both the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, where either of them may be integrated as part of a combined encoder / decoder (CODEC) in a respective device.

The JCT-VC team is working on the development of the HEVC standard. The normalization activities of the HEVC are based on an evolving model of a video coding device called the HEVC (HM) test model. The HM assumes several additional capabilities of video encoding devices over existing devices according to, for example, ITU-T H.264 / AVC. For example, while the H.264 standard provides nine intrapredicting coding modes, the HM can provide up to thirty-three intrapredicting coding modes.

In general, the operation model of the HM describes that a video frame or image can be divided into a sequence of wooded blocks or larger size coding units (LCUs), which include both luma and chroma samples. The syntactic data of a bit stream can define a size for the LCU, which is the largest encoding unit in terms of the number of pixels. A fragment includes a certain number of

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

consecutive wooded blocks in order of coding. A plot or video image can be divided into one or more fragments. Each wooded block can be separated into coding units (CU) according to a quadruple tree. In general, a quadruple tree data structure includes one node per CU, where a root node corresponds to the tree block. If a CU is divided into four sub-CUs, the node corresponding to the CU includes four leaf nodes, each of which corresponds to one of the sub-CUs.

Each node of the quad tree data structure can provide syntactic data for the corresponding CU. For example, a node in the quad tree can include a division indicator, which indicates whether the CU corresponding to the node is divided or not into several sub-CU. The syntactic elements of a CU can be defined recursively and can depend on whether the CU is divided into several sub-CUs. If a CU is not further divided, it is called Cu sheet. In this disclosure, four sub-CU of a CU sheet will also be called CU sheet although there is no explicit division of the original CU sheet. For example, if a CU with a size of 16x16 is not further divided, the four sub-CU of size 8x8 will also be called a CU sheet although the CU of size 16x16 has never been divided.

A CU has a purpose similar to a macroblock of the H.264 standard, except that a CU does not have a size distinction. For example, a wooded block can be divided into four secondary nodes (also called sub-CU) and each secondary node can in turn be a main node and be divided into four other secondary nodes. A final, undivided secondary node, called a leaf node of the quadruple tree, comprises a coding node, also called CU leaf. The syntactic data associated with an encoded bit stream can define a maximum number of times that a wooded block can be divided, called maximum CU depth, and can also define a minimum size of the coding nodes. Therefore, a bit stream can also define a minimum coding unit (SCU). This disclosure uses the term "block" to refer to anyone between a CU, PU or TU, in the context of HEVC, or similar data structures in the context of other standards (for example, macroblocks and subblocks thereof in H. 264 / AVC).

A CU includes a coding node and prediction units (PU) and transform units (TU) associated with the coding node. A size of the CU corresponds to a size of the coding node and must be square. The size of the CU can vary from 8 x 8 pixels to the size of the wooded block, with a maximum of 64 x 64 pixels or more. Each CU may contain one or more PU and one or more TU. Syntactic data associated with a CU may describe, for example, the division of the CU into one or more PU. The modes of division may differ depending on whether the CU is encoded in skip or direct mode, encoded in intraprediction mode or encoded in interprediction mode. PUs can be divided so as not to have a square shape. The syntactic data associated with a CU can also describe, for example, the division of the CU into one or more TU according to a quad tree. A TU can be square or non-square (for example, rectangular).

The HEVC standard supports transformations according to TU, which may be different for different CU. The size of the TU is typically based on the size of the PUs of a given CU defined for a split LCU, although it may not always be so. TUs typically have the same size or smaller size as PU. In some examples, the residual samples corresponding to a CU can be subdivided into smaller units by a quadruple tree structure known as "residual quadruple tree" (RQT). The leaf nodes of the RQT can be called transform units (TU). Pixel difference values associated with TU can be transformed to generate transform coefficients, which can be quantified.

A CU sheet may include one or more prediction units (PU). In general, a PU represents a space zone corresponding to the whole, or a part of the corresponding CU, and may include data to retrieve a reference sample for the PU. In addition, a PU includes data related to the prediction. For example, when the PU is encoded in intramode, data for the PU may be included in a residual quadruple tree (RQT), which may include data describing an intraprediction mode for a TU corresponding to the PU. To mention another example, when the PU is coded in intermode, the PU may include data defining one or more motion vectors for the PU. The data defining the motion vector for a PU can describe, for example, a horizontal component of the motion vector, a vertical component of the motion vector, a resolution for the motion vector (for example, quarter pixel precision or precision of pixels of one eighth), a reference image that the motion vector points to and / or a list of reference images (for example, List 0, List 1 or List C) for the vector of movement.

A CU sheet that has one or more PUs can also include one or more transformation units (TU). Transformation units can be specified using an RQT (also called TU quadruple tree structure), as described above. For example, a division indicator can indicate if a CU sheet is divided into four transformation units. Next, each transformation unit can be further divided into more sub-TU. When a TU is not further divided, it can be referred to as YOUR sheet. In general, with regard to intracoding, all TU sheets that belong to a CU sheet share the same mode of intraprediction. That is, the same intraprediction mode is generally applied to calculate predicted values for all TUs of a CU sheet. With regard to intracoding, a video encoder can calculate a residual value for each TU sheet using the intraprediction mode, such as

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

a difference between the part of the CU corresponding to the TU and the original block. A TU is not necessarily limited to the size of a PU. In this way, the TU can be greater or less than a PU. With regard to intracoding, a PU may be co-located with a corresponding TU sheet for the same CU. In some examples, the maximum size of a TU sheet may correspond to the size of the corresponding CU sheet.

In addition, the TU of the CU sheet can also be associated with the respective quaternary tree data structures, called residual quaternary trees (RQTs). That is, a CU sheet can include a quadruple tree that indicates how the CU sheet is divided into several TU . The root node of a quadruple tree of TU corresponds in general to a CU leaf, while the root node of a quadruple tree of CU corresponds in general to a wooded block (or LCU). The TU of the RQT that are not divided are called TU sheet. In general, this disclosure uses the terms CU and TU to refer to a CU sheet and a TU sheet, respectively, unless otherwise indicated.

A video sequence typically includes a series of video frames or images. A group of images (GOP) generally comprises a series of one or more of the video images. A GOP may include syntactic data in a GOP header, in a header of one or more of the images or in other locations, which describe a certain number of images included in the GOP. Each fragment of an image may include syntactic fragment data that describes a coding mode for the respective fragment. A video encoder 20 typically acts on video blocks of individual video fragments in order to encode the video data. A video block may correspond to a coding node of a CU. Video blocks may have fixed or variable sizes and may differ in size according to a specified coding standard.

In one example, the HM supports prediction in various PU sizes. Assuming that the size of a particular CU is 2Nx2N, the HM supports intraprediction in PU sizes of 2Nx2N or NxN and interpretation in symmetric PU sizes of 2Nx2N, 2NxN, Nx2N or NxN. The HM also supports asymmetric division for interprediction in PU sizes of 2NxnU, 2NxnD, nLx2N and nRx2N. In the asymmetric division, one address of a CU is not divided, while the other address is divided into 25% and 75%. The part of the CU corresponding to the 25% division is indicated by an “n” followed by an indication “up”, “down”, “left” or “right”. Thus, for example, "2NxnU" refers to a CU 2Nx2N that is divided horizontally with a PU 2Nx0.5N above and a pU 2Nx1.5N below.

In this disclosure, "NxN" and "N by N" may be used interchangeably to refer to the pixel dimensions of a video block in terms of vertical and horizontal dimensions, for example, 16x16 pixels or 16 by 16 pixels. In general, a 16 x 16 size block will have 16 pixels in the vertical direction (y = 16) and 16 pixels in the horizontal direction (x = 16). Also, a block of size NxN generally has N pixels in a vertical direction and N pixels in a horizontal direction, where N represents a non-negative integer value. Pixels in a block can be arranged in rows and columns. In addition, the blocks do not necessarily have to present the same number of pixels in the horizontal direction and in the vertical direction. For example, the blocks may comprise NxM pixels, where M is not necessarily equal to N.

After the coding of intraprediction or interprediction by means of the PU of a CU, the video encoder 20 can calculate residual data for the TU of the CU. PUs may comprise syntactic data describing a method or mode of generating predictive pixel data in the spatial domain (also referred to as the pixel domain) and the TUs may comprise coefficients in the transformation domain, after the application of a transformation , for example, a discrete cosine transformation (DCT), an entire transformation, a transformation of pdfs or a conceptually similar transformation, to residual video data. The residual data may correspond to pixel differences between pixels of the uncoded image and prediction values corresponding to the PUs. The video encoder 20 can form the TU including residual data for the CU, and then transform the TU to generate transform coefficients for the CU.

After any transform to generate transform coefficients, the video encoder 20 can quantify the transform coefficients. Quantization generally refers to a process in which the transform coefficients are quantized to possibly reduce the amount of data used to represent the coefficients, providing additional compression. The quantization process can reduce the bit depth associated with some or all of the coefficients. For example, a value of n bits can be rounded down to a value of m bits during quantization, where n is greater than m.

After quantization, the video encoder can scan the transformation coefficients, producing a one-dimensional vector from the two-dimensional matrix that includes the quantized transform coefficients. The scan may be designed to place higher energy coefficients (and therefore of lower frequency) on the front of the matrix and to place lower energy coefficients (and therefore higher frequency) on the back of matrix. In some examples, video encoder 20 can use a predefined scan order to explore quantized transform coefficients and generate a vector in

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

series that can undergo entropy coding. In other examples, video encoder 20 can perform an adaptive scan. After exploring the quantized transform coefficients to form a one-dimensional vector, the video encoder 20 can perform the entropy coding of the one-dimensional vector, for example, according to the adaptive variable length coding according to the context (CAVLC), adaptive binary arithmetic coding according to the context (CABAC), adaptive binary arithmetic coding according to the context based on syntax (SBAC), entropy coding by division of probability intervals (PIPE) or other coding procedures by entropy. The video encoder 20 can also perform the entropy coding of syntactic elements associated with the video data encoded for use by the video decoder 30 in decoding the video data.

To perform the CABAC, the video encoder 20 can assign a context of a contextual model to a symbol to be transmitted. The context may refer, for example, to whether the contiguous values of the symbol are non-zero or not. To perform the CAVLC, the video encoder 20 can select a variable length code for a symbol to be transmitted. The code words in the VLC can be constructed so that the relatively shorter codes correspond to more likely symbols, while the longer codes correspond to less probable symbols. In this way, the use of the VLC can allow saving in bits with respect, for example, to the use of code words of equal length for each symbol to be transmitted. The determination of the probability can be based on a context assigned to the symbol.

According to the techniques of this disclosure, a video encoder, such as a video encoder 20 or a video decoder 30, can be configured to encode a set of video parameters (VPS) in one or more layers of video data and to encode one or more layers of video data based, at least in part, on the VPS. Tables 2 and 5, described in more detail below, include sets of examples of syntactic elements of a VPS. Each, or more, of the video data layers may refer to the VPS, that is, the VPS itself. In other words, the VPS can be applied to all layers of a common set of video data, for example, all SVC layers and / or all MVC video data views.

The VPS can include various categories of information. For example, the VPS may include a description of sample size counter (SDCD). That is, for each dimension, the video encoder can signal a set of indexes. Possible dimensions include cnt_p: number of priority layers contained in the encoded video sequence; cnt_d: how many different dependency layers in the bit stream, multiple layers with the same spatial resolution and bit depth can belong to different dependency layers; cnt_t: how many temporary layers in the bit stream; cnt_q: maximum number of quality layers for any dependency layer in the bit stream; and cnt_v: maximum number of views. Bit depth settings may include 8 bits or 12 bits and may be different for different color components. Chroma sampling formats can include 4: 0: 0, 4: 2: 0 and 4: 4: 4.

The VPS can also include a sample rate for feature assignment. If for each dimension the characteristic indicator is not equal to an index that varies from 0 to the sample dimension counter minus 1, you can enter a loop that specifies the characteristic indicator for each characteristic index. The assignment can include, for each dependency index, a specific spatial resolution with a specific bit depth value and a specific chromatic sample format. Note that this can be omitted if there is always a fixed search table in the decoder, for example, 0 may correspond to 4: 2: 0, 1 may correspond to 4: 4: 4 and 2 may correspond to 4: 0: 0. The assignment may additionally or alternatively include: for each temporary id / index, a specific frame rate or average frame rate; for each view index, a specific view id; for each bit depth index, a pair of specific bit depth values for luma and chroma; and for each chroma sampling format, a specific chroma sampling format indicator.

The VPS can also include control parameters and indicators for enabling / disabling tools, such as the following: a pcm_bit_depth_luma_minus1, a pcm_bit_depth_chroma_minus1, a loop_filter_across_slice_flag, a pcm_loop_filter_disable_flag_, un_direct_d_glug, un temporal_dromp_glass, un temporal_dromp_glass, un temporal_dromp_glass sample_adaptive_offset_enabled_flag, an adaptive_loop_filter_enabled_flag, and an inter_4x4_enabled_flag.

The VPS can also include one or more operating point descriptions. Operation points in general describe a subset of a total number of views of video data included in a bit stream. An operation point can include a particular number of views directed to the output, as well as other views that can be used as a reference when decoding, broadcasting or both. A bit stream may include one or more operation points described by the operation point descriptions. Operation point descriptions may include information defining a certain number of maximum operating points, dependence between layers or different views, profile and level for each operating point, bit rate for each operating point, dependence between operating points. , for each operation point, other restrictions, for each operation point, video usability information (VUI) or part of VUl, and / or for each layer or view, VUI or part of VUI. In addition, or alternatively, the operation point descriptions may include, for each operation point, a network abstraction layer unit (NAL) representation of the video encoding layer

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

(VCL) operating point. In some examples, the VCL NAL unit of operation point representation may include, for each dimension, three possible options: (1) a specific index value: for example, for spatial resolution, for bit depth in the format chroma sampling; (2) a range of the index value: for example, for temporary layers, from 0 to the highest time layer id, for quality layers, from 0 to the highest quality layer id; or (3) a list of index values, for example, for views, a list of view index values.

In some examples, the VPS may include data indicative of a maximum number of time layers between layers of a bit stream. That is, video encoder 20 and / or video decoder 30 can be configured to encode a VPS that includes data indicative of a maximum number of time layers for a corresponding bit stream. For example, the video encoder 20 can determine a maximum number of temporary layers and encode the VPS to include data representing the maximum determined number of temporary layers, while the video decoder 30 can decode the VPS to determine the maximum number of temporary layers The video encoder 20 and the video decoder 30 can also encode video data of the bit stream based on the determined maximum number of time layers. For example, the maximum number of temporary layers may influence a certain number of temporary identifiers that are necessary to represent the various temporal layers. To mention another example, the maximum number of time layers can influence the way in which video encoder 20 and video decoder 30 encode identifiers of a reference image, for example, using image order count values ( POC).

As another example, video encoder 20 and video decoder 30 can be configured to encode data from a particular time layer using only current reference data and including the same time layer. In other words, video encoder 20 and video decoder 30 may be configured to avoid encoding data from a particular time layer using reference data from an upper time layer. In this way, it can be ensured that the video decoder 30 accurately decodes video data from a given set of time layers even after secondary bit stream extraction. That is, if secondary bitstream extraction is performed, certain temporary layers above the highest layer of the extradited secondary bitstream will not be available as a reference. By encoding data from each time layer only with reference to data from layers in, or below, the current layer can avoid errors that could otherwise occur as a result of having data in a particular layer depending on data from one layer. upper layer, which would be lost as a result of secondary bitstream extraction.

In some examples, the VPS, additionally or alternatively, includes indicative data, of either or both, between a certain number of images to be rearranged in one or more layers of a bit stream and / or a certain number of images to be stored. in a buffer of decoded images (DPB). As indicated above, such data may be referred to as bit stream restriction information. Accordingly, the destination device 14 can determine the capabilities of the video decoder 30 and use the bit stream restriction information to determine if the corresponding bit stream is appropriate to be decoded by the video decoder 30, or if the destination device 14 should select alternative content (for example, from a network-based content provider, assuming multiple versions of the content are available).

In addition, the video encoder 20 and the video decoder 30 can use the bit stream restriction information during the encoding of the video data. For example, video encoder 20 can ensure that the bit stream restriction information is not violated. That is, assuming that bitstream restriction information indicates that at least N images must be stored in a DPB, video encoder 20 can ensure that no more than N images are included in any combination of one or more image lists. of reference at a given time. To mention another example, assuming that the image reordering information indicates that an image must be displaced by at least M images, the video encoder 20 can ensure that no image moves more than M images. Changing images in this way, in general, corresponds to the difference between the decoding order and the display order of an image. The video decoder 30 can also use this information during encoding, for example, to perform DPB management, such as washing with DPB. Video encoder 20 and video decoder 30 may also use bit stream restriction information, such as the maximum number of images to be stored in the DPB and / or the number of images to be reordered, when encoding the identifier values of the reference image.

In some examples, the VPS, additionally or alternatively, includes data indicative of hypothetical reference decoder parameters (HRD). HRD parameters include, for example, data describing times at which data from an encoded image buffer (CPB) should be deleted. In decoders, such as video decoder 30, the CPB represents a buffer in which encoded video data is stored until the data is ready for decoding. Decoders such as video decoder 30 may also include a decoded image buffer (DPB), in which decoded video data is stored, for example, to be used as reference data of inter-claimed data and to reorder images of a decoding order to an order of

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

display.

The HRD parameters may include data indicating when the particular images of the CPB should be deleted and decoded. Thus, the video encoder 20 can encode the HRD parameters of the VPS to indicate when the images can be removed from the CPB and decoded, while the video decoder 30 can decode the HRD parameters of the VPS to determine when to delete the images of the CPB. Similarly, video encoder 20 and video decoder 30 can encode images according to HRD parameters, for example, in an order of encoding indicated by HRD parameters. In this way, the video encoder 20 and / or the video decoder 30 can be configured to encode a VPS that includes HRD parameters and to encode video data corresponding to the VPS based, at least in part, on the HRD parameters .

The VPS may also include extension data indicating whether the VPS has been extended, for example, to provide data from one or more additional coding tools. Such coding tools may be tools that are different from those of a corresponding video coding standard, such as, for example, ITU-T H.264 / AVC or the next HEVC standard. In addition, such coding tools may require configuration data. This configuration data can be provided in the expansion data of a VPS. Thus, when encoding video data using such encoding tools, the video encoder 20 and / or video decoder 30 can encode a VPS indicating whether there is enlargement data and, if so, VPS enlargement data. In addition, when such magnification data is present, the video encoder 20 and / or the video decoder 30 can execute the corresponding encoding tools to encode the video data using the amplification data.

Several video coding standards define the syntax, semantics and decoding process corresponding to error-free bit streams, any of which conform to a certain profile or level. Video encoding standards generally do not specify the encoder, but the encoder has the task of ensuring that the generated bit streams are compatible with a decoder. In the context of video coding standards, a "profile" corresponds to a subset of algorithms, features or tools and restrictions that apply to them. As defined in the H.264 standard, for example, a "profile" is a subset of the entire bit stream syntax specified by the H.264 standard. A "level" corresponds to the limitations of decoder resource consumption, such as, for example, decoder memory and calculation, which are related to image resolution, bit rate and block processing speed. A profile can be marked with a profile_idc value (profile indicator), while a level can be marked with a level_idc value (level indicator). In accordance with the techniques of this disclosure, profile and level information can be specified in the operating point descriptions, as discussed above.

In some examples, each layer or view of a bit stream refers to the video parameter set (VPS), and a set of layer sequence parameters (LPS) may be active for each layer. An LPS can be kept as light as possible by referring to the VPS in the design. The LPS may include any or all of the information analyzed below. The LPS may include a sample dimension indication indicating, for each dimension, a index for each dimension. For example, if in a VPS, a spatial resolution index 0 is assigned to a spatial characteristic of 320x240 and a spatial resolution index 1 is assigned to 640x480, and the current layer is to be assigned with a resolution of 640x480, the encoder of video 20 and / or video decoder 30 can encode a syntactic element with a value of 1 for the current layer. That is, the video encoder 20 can indicate a value of 1 for the syntactic element to specify the resolution of 640 x 480, while the video decoder 30 can determine that, a current layer with a syntactic element with a value of 1 , has a resolution of 640 x 480, based on the value of 1 of the syntactic element.

The LPS can also include control parameters and tool enable / disable indicators. For example, the control parameters and tool enable / disable indicators can include a pcm_bit_depth_luma_minus1, a pcm_bit_depth_chroma_minus1, a loop_filter_across_slice_flag, a pcm_loop_filter_disable_flag, one or more syntactic elements related to

chroma_pred_from_luma_enabled_flag, a sample_adaptive_offset_enabled_flag, a

adaptive_loop_filter_enabled_flag, and a coding unit (CU) hierarchy.

The LPS may also include information on other types of parameter sets applicable to a fragment, a group of fragments, an image or several images. Each of these parameter sets can refer to a set of specific image parameters (PPS).

The video encoder, such as video encoder 20 and video decoder 30, can be configured to ensure and / or determine that a PPS does not refer to an LPS or a VPS. Therefore, the video encoder can guarantee that each PPS of a bit stream does not refer to an LPS or a VPS. The analysis of a PPS can be independent. When a PPS includes one or more of the same syntactic elements as those of a VPS or an LPS, the syntactic elements of the PPS may overwrite those of the VPS or LPS.

In addition, a video encoder can be configured to encode a set of grouping parameters (GPS)

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

which groups all parameter sets. The video encoder can encode a plurality of different groups within the GPS, each of which has individual GPS identifiers (ids). Each of the groups in the GPS can include a different combination of parameter sets. Thus, a fragment header only has to include a reference to a corresponding GPS id and does not need to include an indication of a type of parameter set. US provisional patent application serial number 61 / 590.702, filed on January 25, 2012, also describes techniques in which different types of parameter sets are grouped and only the RBSP ID of the parameter set grouping is indicated in the header of the fragment in greater detail.

As discussed above, the video encoder, such as video encoder 20 or video decoder 30, can be configured to encode a set of video parameters and / or a set of grouping parameters. Examples of a set of video parameters are analyzed in greater detail with respect to FIG. 5, while the examples of a set of grouping parameters are analyzed in greater detail with respect to FIG. 6.

In addition, the video encoder 20 can send syntactic data, such as block-based syntactic data, frame-based syntactic data and GOP-based syntactic data, to the video decoder 30, for example, in a frame header, a header of block, a fragment header or a gOp header. Syntactic GOP data can describe a certain number of frames in the respective GOP, and syntactic frame data can indicate a coding / prediction mode used to encode the corresponding frame.

The video encoder 20 and the video decoder 30 can each be implemented as any among a wide variety of suitable encoder or decoder circuits, as appropriate, such as one or more microprocessors, digital signal processors (DSP), integrated circuits application specific (ASIC), field programmable gate matrices (FPGA), discrete logic circuits, software, hardware, firmware or any combination thereof. Each of the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, each of which may be integrated as part of a combined video encoder / decoder (CODEC). A device that includes video encoder 20 and / or video decoder 30 may comprise an integrated circuit, a microprocessor and / or a wireless communication device, such as a cell phone.

FIG. 2 is a block diagram illustrating an example of video encoder 20 that can implement techniques for encoding sets of parameters and NAL units for one or more layers of video data. The video encoder 20 can perform intracoding and intercoding of video blocks within video fragments. Intracoding is based on spatial prediction to reduce or eliminate spatial redundancy in the video within a given frame or video image. Intercoding is based on temporal prediction to reduce or eliminate temporal redundancy in the video within frames or adjacent images of a video sequence. Intramodality (modality I) may refer to any of several spatial base compression modalities. Intermodos, such as unidirectional prediction (P mode) or bi-prediction (B mode), can refer to any of several time base coding modes.

As shown in FIG. 2, video encoder 20 receives a current video block within a frame of video to be encoded. In the example of FIG. 2, the video encoder 20 includes a mode selection unit 40, a reference image memory 64, an adder 50, a transformation processing unit 52, a quantization unit 54 and an entropy coding unit 56. In turn, the mode selection unit 40 includes a motion compensation unit 44, a motion estimation unit 42, an intra-prediction unit 46 and a division unit 48. For the reconstruction of video blocks, the encoder Video 20 also includes an inverse quantization unit 58, an inverse transformation unit 60 and an adder 62. An unblocking filter (not shown in FIG. 2) can also be included to filter block limits, to eliminate distortions of Pixelated effect of the reconstructed video. If desired, the unblocking filter will typically filter the output of adder 62. Additional filters (in loop or post-loop) may also be used, in addition to the unblocking filter. Such filters are not shown for reasons of brevity but, if desired, they can filter the output of adder 50 (such as a loop filter).

During the encoding process, the video encoder 20 receives a frame or a video fragment to be encoded. The plot or fragment can be divided into multiple blocks of video. The motion estimation unit 42 and the motion compensation unit 44 perform the interpredictive encoding of the received video block, with respect to one or more blocks of one or more reference frames, to provide the temporal prediction. The intraprediction unit 46, as an alternative, can perform the intrapredictive encoding of the received video block, with respect to one or more contiguous blocks of the same frame or fragment as the block to be encoded, to provide the spatial prediction. The video encoder 20 can carry out multiple encoding passes, for example, to select a suitable encoding mode for each block of video data.

In addition, the division unit 48 can divide blocks of video data into sub-blocks, based on the

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

evaluation of the previous division schemes in the previous coding passes. For example, the division unit 48 may initially divide a frame or a fragment into several LCUs, and divide each of the LCUs into several sub-CUs, based on a velocity distortion analysis (for example, velocity distortion optimization ). The mode selection unit 40 can also produce a quad-tree data structure indicating the division of an LCU into several sub-CUs. The CU of leaf nodes of the quad tree may include one or more PU and one or more TU.

The mode selection unit 40 may select one of the coding modes, intra or inter, for example, depending on the error results, and provides the resulting intracoded or intercoded block to adder 50 to generate residual block data and to the adder 62 to reconstruct the encoded block to be used as a reference frame. The mode selection unit 40 also provides syntactic elements, such as motion vectors, intramodality indicators, division information and other such syntactic information, to the entropy coding unit 56.

The motion estimation unit 42 and the movement compensation unit 44 may be highly integrated, but are illustrated separately for conceptual purposes. The motion estimation, performed by the motion estimation unit 42, is the process of generating motion vectors, which estimate the movement of the video blocks. A motion vector, for example, may indicate the displacement of a PU from a video block within a current video frame or image, relative to a predictive block within a reference frame (or other encoded unit), with with respect to the current block that is being encoded within the current frame (or other encoded unit). A predictive block is a block that is revealed to be closely coincident with the block to be encoded in regards to the pixel difference, which can be determined by the sum of an absolute difference (SAD), a sum of square difference (SSD) or other difference metrics. In some examples, the video encoder 20 can calculate values of sub-pixel pixel positions of the reference images stored in the reference image memory 64. For example, the video encoder 20 can interpolate values of positions of a quarter pixel , positions of an eighth pixel or other fractional pixel positions of the reference image. Therefore, the motion estimation unit 42 can perform a motion search with respect to the full pixel positions and the fractional pixel positions, and emit a motion vector with a fractional pixel precision.

The motion estimation unit 42 calculates a motion vector for a PU of a video block of an intercoded fragment, comparing the position of the PU with the position of a predictive block of a reference image. The reference image can be selected from a first list of reference images (list 0) or a second list of reference images (list 1), each of which identifies one or more reference images stored in the image memory of reference 64. The motion estimation unit 42 sends the calculated motion vector to the entropy coding unit 56 and to the motion compensation unit 44.

Motion compensation, performed by the motion compensation unit 44, may involve capturing or generating the predictive block based on the motion vector determined by the motion estimation unit 42. Again, the motion estimation unit 42 and the movement compensation unit 44 can be functionally integrated, in some examples. After receiving the motion vector for the PU of the current video block, the motion compensation unit 44 can locate the predictive block pointed to by the motion vector in one of the reference image lists. Adder 50 forms a residual video block by subtracting the pixel values of the predictive block from the pixel values of the current video block being encoded, generating pixel difference values, as discussed below. In general, the motion estimation unit 42 performs the motion estimation with respect to the luma components, and the motion compensation unit 44 uses the calculated motion vectors based on the luma components, both for the components of chroma as for luma components. The mode selection unit 40 can also generate syntactic elements associated with the video blocks and the video fragment for use by the video decoder 30 when decoding the video blocks of the video fragment.

The intraprediction unit 46 can intra-predict a current block, as an alternative to the interprediction carried out by the motion estimation unit 42 and the movement compensation unit 44, as described above. In particular, the intraprediction unit 46 can determine an intraprediction modality to be used to encode a current block. In some examples, the intraprediction unit 46 may encode a current block using various intraprediction modalities, for example, during different coding passes, and the intraprediction unit 46 (or the mode selection unit 40, in some examples) may select an appropriate intraprediction modality to use among the modalities tested.

For example, the intraprediction unit 46 can calculate velocity-distortion values using a velocity-distortion analysis for the various intraprediction modalities tested, and select the intraprediction modality that has the best velocity-distortion characteristics among the modalities tested. The speed-distortion analysis generally determines a magnitude of distortion (or errors) between a block

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

encoded and an original, uncoded block, which was encoded to generate the encoded block, as well as a bit rate (i.e., a certain number of bits) used to generate the encoded block. The intraprediction unit 46 can calculate proportions from the distortions and speeds of the various coded blocks to determine which intraprediction mode has the best velocity-distortion value for the block.

After selecting an intraprediction mode for a block, the intraprediction unit 46 can provide information, indicative of the intraprediction mode selected for the block, to the entropy coding unit 56. The entropy coding unit 56 can encode the information indicating the selected intraprediction modality. The video encoder 20 may include transmitted bitstream configuration data, which may include a plurality of index tables of intraprediction modalities and a plurality of index tables of modified intraprediction modalities (also referred to as word assignment tables of code), definitions of coding contexts for several blocks and indications of a more probable intraprediction modality, a table of indices of intraprediction modalities and a modified table of indices of intraprediction modalities, to be used in each of the contexts.

The video encoder 20 forms a residual video block by subtracting the prediction data of the mode selection unit 40 from the original video block being encoded. Adder 50 represents the component or components that perform this subtraction operation. The transformation processing unit 52 applies a transformation, such as a discrete cosine transformation (DCT) or a conceptually similar transformation to the residual block, generating a video block comprising residual values of transformation coefficients. The transformation processing unit 52 may carry out other transformations that are conceptually similar to the DCT. Transformations of ondfculas, transformations of integers, transformations of subbands or other types of transformations could also be used.

In any case, the transformation processing unit 52 applies the transformation to the residual block, generating a block of residual transformation coefficients. The transformation can convert residual information, from a domain of pixel values to a domain of transformations, such as a frequency domain. The transformation processing unit 52 can send the resulting transformation coefficients to the quantization unit 54. The quantization unit 54 quantizes the transformation coefficients to further reduce the bit rate. The quantization process can reduce the bit depth associated with some, or all, of the coefficients. The degree of quantization can be modified by adjusting a quantization parameter. In some examples, the quantization unit 54 can then perform a matrix scan that includes the quantized transform coefficients. Alternatively, the entropy coding unit 56 can perform the scan.

After quantization, the entropy coding unit 56 encodes the quantized transformation coefficients entropy. For example, the entropy coding unit 56 can perform context-adaptive variable length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), context-adaptive and syntax-based binary arithmetic coding (SBAC) ), entropy coding by dividing into probability intervals (PIPE) or other entropy coding technique. In the case of context-based entropy coding, the context can be based on contiguous blocks. After the entropy coding performed by the entropy coding unit 56, the encoded bit stream can be transmitted to another device (for example, video decoder 30) or archived for later transmission or recovery.

The inverse quantization unit 58 and the inverse transformation unit 60 apply inverse quantization and inverse transformation, respectively, to reconstruct the residual block in the pixel domain, for example, for later use as a reference block. The motion compensation unit 44 can calculate a reference block by adding the residual block to a predictive block of one of the frames of the reference image memory 64. The motion compensation unit 44 can also apply one or more filters of interpolation to the reconstructed residual block to calculate upstream pixel values and use them in motion estimation. Adder 62 adds the reconstructed residual block to the motion-compensated prediction block, generated by the motion compensation unit 44, to generate a reconstructed video block for storage in the reference image memory 64. The reconstructed video block It can be used by the motion estimation unit 42 and the motion compensation unit 44 as a reference block for intercoding a block of a subsequent video frame.

The video encoder 20 can be further configured to encode a set of video parameters (VPS), a set of layer parameters (LPS) and / or a set of grouping parameters, in accordance with the techniques of this disclosure, as well as a set of SPS sequence parameters), a set of image parameters (PPS), a set of adaptation parameters (APS) or other signaling data structures of this type. More particularly, the entropy coding unit 56 may be configured to encode any or all of these data structures. To the extent that the parameters of these various data structures can affect the encoding performance, the mode selection unit 40 can

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

select appropriate parameters and pass the parameters to the entropy coding unit 56 for inclusion within, for example, a VPS. A user, for example an administrator, can select other parameters, such as a certain number of temporal layers, a certain number of images to be rearranged and a certain number of images to be stored in an intermediate memory of decoded images. In other examples, certain parameters, such as HRD parameters, may arise through the coding process.

The entropy coding unit 56 may encode a VPS to include any or all of the various types of data described in this disclosure. The video encoder 20 can also encode data according to the VPS parameters. More particularly, the video encoder 20 can encode image sequences between one or more layers of video data to which the VPS corresponds according to the VPS parameters.

Thus, the video encoder 20 of FIG. 2 represents an example of a video encoder configured to encode a set of video parameters (VPS) for one or more layers of video data, in which each one or more layers of video data refers to the VPS, and encode one or more layers of video data based, at least in part, on the VPS.

Although generally described with respect to a video encoder, the encoding of a VPS can be performed by other devices, for example, a media support network element (MANE). A MANE may correspond to a network element between a source device (such as source device 12 of FIG. 1) and a destination device (such as destination device 14). The MANE can be configured to encode a VPS in accordance with the techniques of this disclosure. The MANE can generate the VPS using data from other data structures received by the MANE, for example, sets of sequence parameters.

FIG. 3 is a block diagram illustrating an example of video decoder 30 that can implement the coding techniques of sets of parameters and NAL units for one or more layers of video data. In the example of FIG. 3, the video decoder 30 includes an entropy decoding unit 70, a motion compensation unit 72, an intra-prediction unit 74, an inverse quantization unit 76, an inverse transformed unit 78, a reference image memory 82 and an adder 80. The reference image memory 82 may also be referred to as "decoded image buffer" or DPB. In some examples, the video decoder 30 may perform a decoding pass in general reciprocal to the encoding pass described with respect to the video encoder 20 (FIG. 2). The motion compensation unit 72 can generate prediction data based on motion vectors received from the entropy decoding unit 70, while the intraprediction unit 74 can generate prediction data based on intraprediction mode indicators received from the unit of decoding by entropy 70.

During the decoding process, the video decoder 30 receives a bit stream of encoded video representing video blocks of an encoded video fragment and associated syntactic elements from the video encoder 20. The entropy decoding unit 70 of the decoder Video 30 decodes the bit stream entropy to generate quantized coefficients, motion vectors or intraprediction mode indicators and other syntactic elements. The entropy decoding unit 70 refers the motion vectors and other syntactic elements to the motion compensation unit 72. The video decoder 30 can receive the syntactic elements at the level of the video fragment and / or the level of the video block .

When the video fragment is encoded as an intracoded fragment (I), the intraprediction unit 74 can generate prediction data for a video block of the current video fragment, based on a designated intraprediction mode, and previously decoded block data of the current plot or image. When the video frame is encoded as an intercoded fragment (i.e., B, P or GPB), the motion compensation unit 72 generates predictive blocks for a video block of the current video fragment, based on the motion vectors already other syntactic elements received from the entropy decoding unit 70. Predictive blocks can be generated from one of the reference images within one of the reference image lists. The video decoder 30 can construct the reference frame lists, List 0 and List 1, using default construction techniques, based on the reference images stored in the reference image memory 82.

The motion compensation unit 72 determines the prediction information for a video block of the current video fragment, analyzing the motion vectors and other syntactic elements, and uses the prediction information to generate the predictive blocks of the current video block that It is being decoded. For example, the motion compensation unit 72 uses some of the received syntactic elements to determine a prediction mode (for example, intraprediction or interprediction), used to encode the video blocks of the video fragment, a type of interprediction fragment (for example, fragment B, fragment P or fragment GPB), construction information for one or more of the reference image lists of the fragment, motion vectors for each block of intercoded video of the fragment, the state of interprediction for each block of intercoded video of the fragment and other information to decode the video blocks of the current video fragment.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

The motion compensation unit 72 can also perform interpolation based on interpolation filters. The motion compensation unit 72 may use interpolation filters, such as those used by the video encoder 20 during the encoding of the video blocks, to calculate interpolated values of upstream pixels of the reference blocks. In this case, the motion compensation unit 72 can determine the interpolation filters used by the video encoder 20 from the received syntactic elements and use the interpolation filters to generate predictive blocks.

The inverse quantization unit 76 quantifies inversely, that is, it quantifies, the quantized transformation coefficients, provided in the bit stream and decoded by the entropy decoding unit 80. The inverse quantization process may include the use of a QPY quantization parameter, calculated by the video decoder 30 of each video block in the video fragment to determine a degree of quantization and, also, a degree of inverse quantization that should be applied. The inverse transformation unit 78 applies an inverse transformation, for example, an inverse DCT, an entire inverse transformation or an inverse transformation process conceptually similar to the transformation coefficients in order to generate residual blocks in the pixel domain.

After the motion compensation unit 72 generates the predictive block of the current video block, based on the motion vectors and other syntactic elements, the video decoder 30 forms a block of decoded video by adding the residual blocks from the unit of inverse transformation 78 and the corresponding predictive blocks generated by the motion compensation unit 72. Adder 90 represents the component or components that carry out this summing operation. If desired, an unblocking filter can also be applied to filter the decoded blocks in order to eliminate pixelated distortions. Other loop filters can also be used (either in the encoding loop or after the encoding loop) to smooth pixel transitions, or otherwise improve video quality. The decoded video blocks of a given frame or image are then stored in the reference image memory 82, which stores reference images used for subsequent motion compensation. The reference image memory 82 also stores decoded video for later presentation in a display device, such as the display device 32 of FIG. one.

According to the techniques of this disclosure, the video decoder 30 can decode a set of video parameters (VPS), a set of layer parameters (LPS) and / or a set of grouping parameters, according to the techniques of this disclosure, as well as a set of sequence parameters (SpS), a set of image parameters (PPS), a set of adaptation parameters (APS) or other signaling data structures of this type. More particularly, the entropy decoding unit 70 may be configured to decode any or all of these data structures. By decoding these various data structures, the entropy decoding unit 70 can determine parameters that will be used to decode corresponding video data. For example, video decoder 30 can decode corresponding sequences of video data from one or more layers using parameters of a decoded VPS.

Although not shown in FIG. 3, video decoder 30 may additionally include a buffer of decoded images (CPB). Normally, the CPB would ordinarily be provided before the entropy decoding unit 70. Alternatively, the CPB may be coupled to the entropy decoding unit 70 for temporary storage, or to the output of the entropy decoding unit 70 to store entropy decoded data until said data is decoded. In general, the CPB stores encoded video data until the encoded video data is to be decoded, for example, as indicated by the HRD parameters, that the video decoder 30 can extract from a decoded VPS. Similarly, other elements of the video decoder 30 may be configured to decode video data using, for example, the VPS. For example, video decoder 30 can decode temporary identifiers of images of several temporal layers, data indicating a certain number of images to be rearranged and / or stored in the memory of reference images 82 (representing a DPB).

In addition, the video decoder 30 may include additional processing units for processing video data in accordance with various encoding tools provided by extensions of a video encoding standard. Alternatively, the existing elements of the video decoder 30 shown in FIG. 3 can be configured to execute the coding tools of such extensions. The entropy decoding unit 70 may be configured to decode VPS extension data and provide such extension data to the units configured to execute the coding tools provided by the extensions.

In this way, the video decoder 30 of FIG. 3 represents an example of a video decoder configured to encode a set of video parameters (VPS) for one or more layers of video data, in which each of one or more layers of video data refers to the VPS, and encode one or more layers of video data based at least in part on the VPS.

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Although generally described with respect to a video decoder, the decoding of a VPS can be performed by other devices, for example, a network element that knows the means (MANE). The MANE can be configured to decode a VPS in accordance with the techniques of this disclosure. The MANE can also generate other parameter set data, such as one or more sequence parameter sets, using the VPS data. In this way, MANE can provide retrospective compatibility with previous standards, such as ITU-T H.264 / AVC.

FIG. 4 is a conceptual diagram illustrating an example pattern of the MVC standard as an example. Multivist video coding (MVC) is an extension of ITU-T H.264 / AVC. A similar technique can be applied to HEVC. In the example of FIG. 4, eight views are illustrated (with view ID "S0" to "S7") and twelve time positions ("T0" to "T11") are illustrated for each view. That is, each row of FIG. 4 corresponds to a view, while each column indicates a temporary location.

A typical MVC prediction structure (which includes both the prediction between images within each view and the prediction between views) for multivist video coding is shown in FIG. 4, where predictions are indicated by arrows, where the object to which it is pointed uses the object from which it is pointed as a prediction reference. In MVC, the prediction between views is compatible with disparity motion compensation, which can use the H.264 / AVC motion compensation syntax, but allows you to use an image in a different view as a reference image.

The coding of two views could also be compatible with MVC, and one of the advantages of MVC is that an MVC encoder could take more than two views as a 3D video input and an MVC decoder can decode a multivist representation. Thus, any MVC decoder renderer can be configured to receive 3D video content with more than two views.

Although MVC has a so-called base view that is decodable by H.264 / AVC decoders and the stereo view pair could also be compatible with MVC, an advantage of MVC is that it could allow an example that uses more than two views as a 3D video input and decode this 3D video represented by multiple views. A renderer of a client that has an MVC decoder can expect 3D video content with multiple views.

A typical MVC decoding order is called first-time coding. An access unit may include encoded images of all views for an instance of exit time. For example, each of the images of the time T0 may be included in a common access unit, each of the images of the time T1 may be included in a second common access unit, and so on. The decoding order is not necessarily identical to the output or display order.

The frames in FIG. 4 are indicated at the intersection of each row and each column of FIG. 4 using a shaded block that includes a letter, which designates whether the corresponding frame is intracoded (i.e., a frame I), or intercoded in one direction (i.e., as a P frame) or in multiple addresses (i.e., as a plot B). In general, predictions are indicated by arrows, where the plot to which the object is pointed to is used as the reference reference. For example, frame P of view S2 at temporary location T0 is predicted from frame I of view S0 at temporary location T0.

As with single view video encoding, frames of a multivist video encoding video sequence can be predictively encoded with respect to frames in different time locations. For example, frame B of view S0 at temporary location T1 has an arrow pointing to it from frame I of view S0 at temporary location T0, which indicates that frame B is predicted from frame I. Additionally, however, in the context of multivist video coding, frames can be predicted between views. That is, a view component can use the view components in other views as a reference. In MVC, for example, the prediction between views is made as if the view component in another view is an interprediction reference. The possible references between views are indicated in the extension of the MVC standard of the sequence parameter set (SPS) and can be modified by the process of constructing the reference image list, which enables the flexible ordering of the reference references. interprediccion or prediction between views.

In the MVC extension of H.264 / AVC, for example, the prediction between views is compatible with disparity motion compensation, which uses the H.264 / AVC motion compensation syntax, but allows a image in a different view as a reference image. The coding of two views can be compatible with MVC, which is generally called stereoscopic views. One of the advantages of MVC is that an MVC encoder could take more than two views as a 3D video input and an MVC decoder can decode a multivist representation. Therefore, a rendering device with an MVC decoder can expect 3D video content with more than two views.

In MVC, prediction between views (IVP) between images in the same access unit is allowed (that is, with the

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

same time instance). An access unit is, in general, a data unit that includes all view components (for example, all NAL units) for a common temporary instance. Therefore, in MVC, prediction between views between images in the same access unit is allowed. When an image is encoded in one of the non-basic views, the image can be added to a list of reference images, if it is in a different view but with the same time instance (for example, the same POC value and, therefore, both, in the same access unit). A prediction reference image between views can be placed in any position of a reference image list, as is the case with any interprediction reference image.

In the context of multivist video coding there are two types of motion vectors. One is normal motion vectors that point to temporal reference images, and the corresponding mode of interprediction is called a motion-compensated prediction (MCP). The other are disparity motion vectors that point to images in a different view, and the corresponding prediction mode between views is called disparity compensated prediction (DCP).

In conventional HEVC, there are two modes for prediction of motion parameters: one is the fusion mode and the other is advanced motion vector prediction (AMVP). In the merge mode, a list of motion parameter candidates (reference images and motion vectors) is constructed where the candidate can be of adjacent spatial or temporal blocks. The spatially and temporarily contiguous blocks can form a list of candidates, that is, a set of candidates from which movement prediction information can be selected. Accordingly, video encoder 20 can encode the motion parameters chosen as motion prediction information by encoding an index in the candidate list. After the video decoder 30 has decoded the index, all motion parameters of the corresponding block to which the index points can be inherited, in the combination mode.

In AMVP, according to conventional HEVC, a list of motion vector predictor candidates is obtained for each movement hypothesis based on the coded reference index. This list includes contiguous block motion vectors that are associated with the same reference index, as well as a temporal motion vector predictor that is obtained based on the motion parameters of the contiguous block of the colocalized block in a temporal reference image. The chosen motion vectors are indicated by transmitting an index to the list of candidates. In addition, the values of the reference index and the differences of the motion vector are also indicated.

FIG. 4 provides several examples of prediction between views. The frames of the view S1, in the example of FIG. 4, are illustrated as predicted from images in different temporary locations of the view S1, as well as predicted between views from frames of the view frames S0 and S2 in the same temporary locations. For example, frame B of view S1 at temporary location T1 is predicted from each of frames B of view S1 at temporary locations T0 and T2, as well as frames B of views S0 and S2 in the temporary location T1.

In the example of FIG. 4, the capital letter "B" and the lowercase "b" are designed to indicate different hierarchical relationships between the frames, rather than different coding methodologies. In general, frames with a capital "B" are relatively higher in the prediction hierarchy than frames with a lowercase "b". FIG. 4 also illustrates the variations in the prediction hierarchy using different levels of shading, where frames with a greater magnitude of shading (i.e., relatively darker) are higher in the prediction hierarchy than those frames that have less shading (it is say, relatively clearer). For example, all frames I in FIG. 4 are illustrated with full shading, while the P frames have a somewhat lighter shading, and the B frames (and the lowercase b frames) have different levels of shading, but always lighter than the shading of the P and plots I.

In general, the prediction hierarchy is related to indices of the order of view, in that the relatively higher frames in the prediction hierarchy should be decoded before decoding frames that are relatively lower in the hierarchy, such so those relatively higher frames in the hierarchy can be used as reference frames during decoding of relatively lower frames in the hierarchy. A view order index is an index that indicates the order of decoding of view components in an access unit. The order of view indices are implicit in the SPS MVC extension, as specified in Annex H of H.264 / AVC (the MVC amendment). In the SPS, for each index i, the corresponding view_id is signaled. In some examples, decoding of the view components will follow the ascending order of the view order index. If all views are presented, the view order indices are in a consecutive order from 0 to num_views_minus_1.

In this way, frames used as reference frames can be decoded before decoding frames that are encoded with reference to reference frames. A view order index is an index that indicates the order of decoding of view components in an access unit. For each display order index i, the corresponding view_id is signaled. The decoding of the view components follows the ascending order of the view order indices. If all views are presented, then the

5

10

fifteen

twenty

25

30

35

set of view order indices can comprise a consecutively ordered set from zero to one less than the total number of views.

For certain frames at equal levels in the hierarchy, the order of decoding between them may not matter. For example, frame I of the view S0 in the temporary position T0 is used as a reference frame for the frame P of the view S2 in the temporary position T0, which in turn is used as a reference frame for the frame P of S4 view in temporary position T0. Consequently, the frame I of the view S0 in the temporary position T0 should be decoded before the frame P of the view S2 in the temporary position T0, which should be decoded before the frame P of the view S4 in the temporary position T0 . However, between views S1 and S3, an order of decoding does not matter, because views S1 and S3 are not based on each other for prediction, but are predicted only from views that are higher in the prediction hierarchy. In addition, view S1 can be decoded before view S4, provided that view S1 is decoded after views S0 and S2.

In this way, a hierarchical order can be used to describe views S0 to S7. Let the SA> SB notation mean that the SA view must be decoded before the SB view. Using this notation, S0> S2> S4> S6> S7, in the example of FIG. 4. Also with respect to the example of FIG. 4, S0> S1, S2> S1, S2> S3, S4> S3, S4> S5 and S6> S5. Any decoding order for views that does not violate these requirements is possible. Consequently, many different decoding orders are possible with only certain limitations.

According to the techniques of this disclosure, each of the S0-S7 views can be considered a respective layer of a corresponding bit stream. Thus, a VPS can describe bitstream parameters applicable to any of, or all, views S0-S7, while sets of individual layer parameters can be provided for any of, or all, views S0-S7. In addition, a set of grouping parameters can be provided for a group of parameter sets, so that fragments within individual images of views S0-S7 can simply refer to the identifier of a set of grouping parameters.

As shown in FIG. 4, a view component can use the view components in other views as a reference. This is called prediction between views. In MVC, the prediction between views is made as if the view component in another view was an interprediction reference. The video encoder 20 and the video decoder 30 can encode the possible references between views in the MVC extension of the Sequence Parameter Set (SPS) (as shown in the example in Table 1). The video encoder 20 and the video decoder 30 can additionally modify the possible references between views by executing the process of constructing a reference image list, which may allow the flexible ordering of the prediction references between views or interprediction.

TABLE 1

 seq_parameter_set_mvc_extension () {

 C Descriptor

 num_views_minus1

 0 eu (v)

 for (i = 0; i <= num_views_minus1; i ++)

 view_id [i]

 0 eu (v)

 for (i = 1; i <= num_views_minus1; i ++) {

 num_anchor_refs_l0 [i]

 0 eu (v)

 for (j = 0; j <num_anchor_refs_l0 [i]; j ++)

 anchor_ref_l0 [i] [j]

 0 eu (v)

 num_anchor_refs_l1 [i]

 0 eu (v)

 for (j = 0; j <num_anchor_refs_l1 [i]; j ++)

 anchor_ref_l1 [i] [j]

 0 eu (v)

 }

 for (i = 1; i <= num_views_minus1; i ++) {

 num_non_anchor_refs_l0 [i]

 0 eu (v)

 for (j = 0; j <num_non_anchor_refs_l0 [i]; j ++)

 non_anchor_ref_l0 [i] [j]

 0 eu (v)

 num_non_anchor_refs_l1 [i]

 0 eu (v)

 for (j = 0; j <num_non_anchor_refs_l1 [i]; j ++)

 non_anchor_ref_l1 [i] [j]

 0 eu (v)

5

10

fifteen

twenty

25

30

35

40

Four. Five

 }

 num_level_values_signaled_minus1

 0 eu (v)

 for (i = 0; i <= num_level_values_signaled_minus1; i ++) {

 level_idc [i]

 0 u (8)

 num_applicable_ops_minus1 [i]

 0 eu (v)

 for (j = 0; j <= num_applicable_ops_minus1 [i]; j ++) {

 applicable_op_temporal_id [i] [j]

 0 u (3)

 applicable_op_num_target_views_minus1 [i] [j]

 0 eu (v)

 for (k = 0; k <= applicable_op_num_target_views_minus1 [i] [j]; k ++)

 applicable_op_target_view_id [i] [j] [k]

 0 eu (v)

 applicable_op_num_views_minus1 [i] [j]

 0 eu (v)

 }

 }

 }

In the SPS MVC extension shown in Table 1, for each view, the number of views that can be used to form the reference image list 0 and the reference image list 1 are indicated. The prediction relationship for an image Anchoring, as noted in the SPS MVC magnification, may be different from the prediction ratio for an image without anchoring (noted in the SPS MVC magnification) of the same view.

Video coding standards include ITU-T H.261, ISO / IEC MPEG-1 Visual, ITU-T H.262 or ISO / IEC MPEG-2 Visual, ITU-T H.263, ISO / IEC MPEG -4 Visual and ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC), including its scaling video scaling (SVC) and multivist video coding (MVC) extensions.

In addition, there is a new video coding standard, specifically the High Efficiency Video Coding (HEVC) that is being developed by the Joint Collaboration Team on Video Coding (JCT-VC) of the Group of Experts on Video Coding ( VCEG) of ITU-T and the Group of Experts in Motion Pictures (MPEG) of ISO / IEC. A recent Working Draft (BT) of the HEVC, and referred to as HEVC WD4 onwards, is available at
http://phenix.int-evry.fr/jct/doc_end_user/documents/6_Torino/wg11/JCTVC-F803-v3.zip, denoted as HEVC WD4d1.

The sequence and image parameter set mechanism decouples the transmission of information that changes infrequently from the transmission of encoded block data. In some applications, sets of sequence and image parameters can be transported "out of band" using a reliable transport mechanism. An unprocessed byte sequence payload (RBSP) of a set of image parameters may include parameters to which the encoded fragment network (NAL) abstraction layer units of one or more encoded images may refer. One or more RBSP of a set of sequence parameters may include parameters that may be referred to by one or more RBSP of a set of image parameters or one or more NAL units of complementary enhancement information (SEI) that contain a SEI message of Intermediate storage period. An RBSP of a set of sequence parameters may include parameters that may be referenced by one or more RBSP of a set of image parameters or one or more SEI NAL units that contain an intermediate storage period SEI message.

The sequence parameter set may include an optional set of parameters called video usability information (VUI). The VUI may include the following three categories of optional information: video representation information, hypothetical reference decoder information (HRD) and bitstream restriction information. The video representation information includes the aspect ratio, chroma phase changes of color space transformation information related to luma and frame rate. The HRD includes video buffer parameters for encoded video streams. The bit stream restriction information includes restrictions on the range of the motion vector, the size of the decoded image buffer (DPB) and the number of rearrange frames and the encoded block sizes (e.g., macroblocks or units of coding (CU)) and images.

HEVC WD5 includes the set of support adaptation parameters (APS). The concept of adaptation parameter set (APS) can also be found in JCTVC-F747, available at
http: //phenix.int- evry.fr/jct/doc_end_user/documents/6_Torino/wgl11JCTVC-F747-v4.zip.

A unified NAL unit header can be used for both non-scalable HEVC bit streams and for

the scalable bit streams that fit the scalable or multivist potential extensions of HEVC. A unified NAL unit header may differ from the current NAL HEVC unit header in the following aspects: there may be a fixed NAL unit header length for a complete encoded video sequence, while the length may vary between encoded video sequences different, and an effective coding of the scalability syntactic elements in the NAL unit header and, when a particular syntactic element is not necessary, it does not need to be present. In such a design, a type of NAL unit or a different set of parameters can be used for the entire bit stream.

10

fifteen

twenty

 video_parameter_set_rbsp () {

 Descriptor

 video_para_set_id

 u (8)

 // description of the sample dimension counter

 cnt_p

 u (3)

 cnt_d

 u (3)

 cnt_t

 u (3)

 cnt_q

 u (3)

 cnt_v

 u (4)

 cnt_f

 u (4)

 // sample index for feature assignment

 for (i = 0; i <cnt_d; i ++) {

 pic_width_in_luma_samples [i]

 eu (v)

 pic_height_in_luma_samples [i]

 eu (v)

 bit_depth_luma_minus8 [i]

 eu (v)

 bit_depth_chroma_minus8 [i]

 eu (v)

 chroma_format_idc [i]

 u (2)

 }

 for (i = 0; i <cnt_t; i ++)

 averge_frame_rate [i]

 u (16)

 yes (cnt_v> 1)

 for (i = 0; i <cnt_v; i ++)

 view_id [i]

 eu (v)

 // control parameters and tools enable / disable indicators

 log2_max_pic_order_cnt_lsb_minus4

 eu (v)

 chroma_pred_from_luma_enabled_flag

 u (l)

 loop_filter_across_slice_flag

 u (l)

 sample_adaptive_offset_enabled_flag

 u (l)

 adaptive_loop_filter_enabled_flag

 u (l)

 pcm_loop_filter_disable_flag

 u (l)

 cu_qp_delta_enabled_flag

 u (l)

FIG. 5 is a conceptual diagram illustrating a set of video parameters (VPS) and several sets of layer parameters (LPS). The ellipses that follow the second LPS of FIG. 5 are intended to indicate that there can be any VPS number N, where N is an integer. For example, each layer (for example, each SVC layer or each MVC view) can have a corresponding LPS. A video encoder, such as video encoder 20 or video decoder 30, can be configured to encode a VPS and one or more LPS, as illustrated in FIG. 5.

Table 2 below provides an example of raw byte sequence payload (RBSP) syntax for a VPS.

TABLE 2

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

 temporary_id_nesting_flag

 u (l)

 inter_4x4_enabled_flag

 u (l)

 operation_point_desription ()

 vps_extension_flag

 u (l)

 yes (vps_extension_flag)

 while (more_rbsp_data ())

 vps_extension_data_flag

 u (l)

 rbsp_trailing_bits ()

 }

Video encoders can be configured such that an encoded video sequence (for example, a bit stream that includes one or more layers) can only have one set of active video parameters (VPS). The VPS can be encapsulated within a NAL unit of a particular type. For example, the nal_unit_type for an RBSP VPS can be 10. The sample semantics for the VPS in Table 2 are described below:

In this example, video_para_set_id identifies a corresponding set of video parameters (VPS).

In this example, cnt_p specifies the maximum number of priority_id values present in the corresponding encoded video sequence.

In this example, cnt_d specifies the maximum number of dependency layers present in the corresponding encoded video sequence. Several views with the same resolution can be considered as belonging to the same dependency layer. Two layers of dependence can have the same spatial resolution.

In this example, cnt_t specifies the maximum number of temporal layers present in the encoded video sequence.

In this example, cnt_q specifies the maximum number of quality layers present in a dependency layer in the encoded video sequence.

In this example, cnt_v specifies the maximum number of views present in the encoded video sequence.

In this example, cnt_f specifies the number of bits used to represent the reserved_flags syntax element in the NAL unit header.

In this example, pic_width_in_luma_samples [i] and pic_height_in_luma_samples [i] specify, respectively, the width and height of the ith resolution of the dependency layer in luma sample units.

In this example, bit_depth_luma_minus8 [i] plus 8 and bit_depth_chroma_minus8 [i] plus 8 specifies the bit depth of the luma and chroma components of the i-th representation of bit depth.

In this example, chroma_format_idc [i] specifies the chroma sample format of the ith representation of the chroma sample format. For example, a value equal to 0 may indicate 4: 2: 0; a value equal to 1 may indicate 4: 4: 4, a value equal to 2 may indicate 4: 2: 2 and a value equal to 3 may indicate 4: 0: 0.

In this example, average_frame_rate [i] specifies the average speed of the ith representation of the time layer in frame units for 256 seconds.

In this example, view_id [i] specifies the view identifier of the ith view, which has a view order index equal to i. When not present, it can be inferred that the value of view_id [0] is 0. vps_extension_flag equal to 0 specifies that there are no vps_extension_data_flag syntactic elements present in the RBSP syntax structure of the video parameter set. vps_extension_flag can be equal to 0 in bit streams according to the next HEVC standard. The value 1 for vps_extension_flag can be reserved, for example, for future use by ITU-T | ISO / IEC Decoders, such as video decoder 30, can ignore all data that follows the value 1 for vps_extension_flag in a NAL unit of the video parameter set.

In this example, vps_extension_data_flag can have any value. It does not affect compliance with the profiles specified in the next HEVC standard, but allows the further development of the next standard.

Other syntactic elements in the VPS may have the same semantics as the syntactic elements with the same names in the SPS of the current HEVC work draft. These syntactic elements can be applied to the encoded video sequence that refers to this VPS, unless they are overwritten by sets of

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

lower level parameters.

In some examples, a 3DV_flag signal can be additionally indicated in the VPS to indicate if the depth is present in the encoded video sequence.

In some examples, the VUI parameters are signaled in the LPS.

In some examples, the syntactic elements cnt_p, cnt_t, cnt_d, cnt_q and cnt_v specify the numbers of bits used to encode priority_id, temporal_id, dependency_id, quality_id and view_idx, respectively, and the maximum numbers of priority_id values, temporal layers, dependency layers , quality layers and views present in the encoded video sequences can also be signaled in the VPS.

In some examples, another type of NAL unit can be introduced to contain the syntactic elements cnt_p, cnt_t, cnt_d, cnt_q, cnt_v and cnt_f. This new type of NAL unit can also include an identifier (ID) and the ID can be referenced in the VPS.

In some examples, the syntactic elements of

log2_max_pic_order_cnt_lsb_minus4 to inter_4x4_enabled_flag in Table 2 are not signaled in the VPS, but instead, the video encoder 20 and the video decoder 30 can encode these syntactic elements in the LPS.

In some examples, the operation_point_desription () syntax structure in Table 2 is not included in the VPS; instead, the video encoder 20 and the video decoder 30 or other elements (for example, the output interface 22 and / or the input interface 28), can encode the content in the syntax structure of operation_point_description () in a complementary improvement information message (SEI).

In some examples, video encoder 20 and / or video decoder 30 may encode video usability information (VUI) parameters in the VPS. For example, a VPS may include data specifying bit flow restriction information, such as restrictions on the range of motion vectors, DPB size, number of reordering frames and coded block sizes (e.g., macroblocks or CU) and images. In this way, a VPS can specify information indicating a DPB size required for a video decoder (such as video decoder 30) to properly decode a corresponding bit stream, that is, a bit stream that includes the VPS. Similarly, a VPS can specify image reordering information, that is, a certain number of images that can precede a given image in decoding order and that happen to the given image in output order (i.e., order of display).

Additionally or alternatively, a VPS may include data specifying hypothetical reference decoder (HRD) information. As indicated above, video encoder 20 and / or video decoder 30 can encode (i.e., signal) VUI parameters, which may include HRD information in the VPS. Therefore, a VPS may include data describing, for example, operating points of a corresponding bit stream. For example, a VPS may include data describing one or more of a certain number of maximum operating points, dependencies between layers or different views, profile and level information for each operating point, representation of VCL NAL unit of point of operation for each point of operation, bit rate for each point of operation, dependence between points of operation, restrictions for each point of operation, VUI or partial VUI for each point of operation and / or VUI or partial VUI for each layer or view .

A VPS can also include for each dimension: a specific index value, a range of index values or a list of index values. For example, when a VPS includes data describing a specific index value, the index value may correspond, for a spatial resolution, to the bit depth for the chroma sampling format. To mention another example, when a VPS includes a range of index values, for time layers, the range may range from zero (0) to the highest time layer ID, and for quality layers, the range may range from zero ( 0) to the highest quality layer ID. As another example, when a VPS includes data describing a list of index values, the list may comprise a list of view index values for multiple views.

In some examples, video encoder 20 may encode (i.e., signal) and the video decoder may decode, one or more representation format parameters (width, height, bit depth, etc.) and there may be different sets of representation format parameters. A layer or point of operation can then refer to an index of said set of representation format parameters. An example of the syntax design for such a set is shown in Table 3 below.

TABLE 3

num_rep_formats_minus1

eu (v)

 for (i = 0; i <= num rep formats minusl; i ++) {

 pic_width_in_luma_samples [i]

 eu (v)

 pic_height_in_luma_samples [i]

 eu (v)

 bit_depth_luma_minus8 [i]

 eu (v)

 bit_depth_chroma_minus8 [i]

 eu (v)

 chroma_format_idc [i]

 u (2)

 }

 for (i = 0; i <cnt_d; i ++) {

 rep_format_idx [i]

 eu (v)

 }

In some examples, instead, the ref_format_idx can be signaled in the set of layer parameters.

5

Table 4 below provides an example syntax for the operation point descriptions.

TABLE 4

 operation_points_description () {

 Descriptor

 num_operation_point_minus1

 eu (v)

 for (i = 0; i <= num_operation_points_minus1; i ++) {

 op_profile_level_idc [i]

 u (24)

 operation_point_id [i]

 eu (v)

 priority_id [i]

 eu (v)

 temporary_id [i]

 eu (v)

 quality_id [i]

 eu (v)

 dependency_id [i]

 eu (v)

 if (cnt_v> 1) {

 num_target_output_views_minus1 [i]

 eu (v)

 for (j = 0; j <= num_target_output_views_minus1 [i]; j ++)

 view_idx [i] [j]

 eu (v)

 }

 frm_rate_info_present_flag [i]

 u (l)

 avg_bitrate [i]

 u (16)

 max_bitrate [i]

 u (16)

 max_bitrate_calc_window [i]

 u (16)

 constant_frm_rate_idc [i]

 u (2)

 yes (cnt_v> 1) {

 num_directly_dependent_views [i]

 for (j = 0; j <num directly dependent views [i]; j ++) {

 directly_dependent_view_idx [i] [j]

 }

 }

 yes (cnt_v> 1)

 for (i = 1; i <cnt_v; i ++) {

 num_ref_views [i]

 eu (v)

 for (j = 0; j <num_ref_views [i]; j ++)

 ref_view_idx [i] [j]

 eu (v)

5

10

fifteen

twenty

25

30

35

40

 }

 }

Examples of the semantics of the syntactic elements of Table 4 are analyzed below:

In this example, num_operation_point_minus1 plus 1 specifies the maximum number of operating points that are present in the encoded video sequence and for which the operating point information is signaled by the following syntactic elements.

In this example, op_profile_level_idc [i], operation_point_id [i], priority_id [i], num_target_output_views_minus1 [i], frm_rate_info_present_flag [i], avg_bitrate [i], max_bitrate [i], max_bitrate_calc_wid__dec_direct_window [id] [I] can have the same semantics as the syntactic elements with the same names in the H.264 scalability information SEI message.

In this example, quality_id [i] and dependency_id [i] can have the same semantics as the syntactic elements with the same names in the H.264 scalability information SEI message.

In this example, directly_dependent_view_idx [i] [j] specifies the view index of the jth view on which the target output view of the current operating point directly represents the current operating point.

In this example, num_ref_views [i] specifies the number of view components for prediction between views in the initial reference image list RefPicList0 and RefPicList1 in decoding view components with view order index equal to i. In this example, the value of the num_ref [i] views will not be greater than Min (15, num_views_minus1). In some examples, the value of num_ref_views [0] is equal to 0.

In this example, ref_view_idx [i] [j] specifies the view order index of the jth view component for prediction between views in the initial reference image list RefPicList0 and RefPicList1 in decoding a view component with order of view index equal to i. In this example, the value of ref_view_idx [i] [j] will be in the range of 0 to 31, inclusive.

In some examples, as an alternative, some of the syntactic elements of the SEI scalability information message (for example, as described in H.264), for example, the syntactic elements related to the layer dependency information, may be included in the operation_points_description () syntax structure of Table 4.

In some examples, video encoder 20 and / or video decoder 30 may encode (i.e., signal) some VUI parameters in the operation_points_description () syntax structure of Table 4.

Table 5 below provides an alternative syntax for a set of video parameters:

TABLE 5

 video_parameter_set_rbsp () {

 Descriptor

 video_parameter_set_id

 eu (v)

 num_temporal_layers_minus1

 u (3)

 for (i = 0; i <= num_temporal_layers_minus1; i ++) {

 profile_idc [i]

 u (8)

 reserved_zero_8bits [i] / * equal to 0 * /

 u (8)

 level_idc [i]

 u (8)

 }

 bit_depth_luma_minus8

 eu (v)

 bit_depth_chroma_minus8

 eu (v)

 chroma_format_idc

 u (2)

 pic_width_in_luma_samples

 eu (v)

 pic_height_in_luma_samples

 eu (v)

 pic_cropping_flag

 u (1)

 yes (pic_cropping_flag) {

 pic_crop_left_offset

 eu (v)

 pic_crop_right_offset

 eu (v)

 pi c_c rop_top_offset

 eu (v)

 pic_crop_botto m_offs et

 eu (v)

 }

 temporary_id_nesting_flag

 u (1)

 bit_equal_to_one / * equal to 1 * /

 u (1)

 extension_type / * equal to 0 for 3DV * /

 eu (v)

 num_layers_minus2

 eu (v)

 num_rep_formats_minus1

 eu (v)

 for (i = 1; i <= num_rep_formats_minus1; i ++) {

 bit_depth_luma_minus8 [i]

 eu (v)

 bit_depth_chroma_minus8 [i]

 eu (v)

 chroma_format_idc [i]

 u (2)

 pic_width_in_luma_samples [i]

 eu (v)

 pic_height_in_luma_samples [i]

 eu (v)

 pic_cropping_flag [i]

 u (1)

 yes (pic_cropping_flag [i]) {

 pic_crop_left_offset [i]

 eu (v)

 pic_crop_right_offset [i]

 eu (v)

 pic_crop_top_offset [i]

 eu (v)

 pic_crop_bottom_offset [i]

 eu (v)

 }

 }

 for (i = 1; i <= num_layers_minus1; i ++) {

 rep_format_idx [i]

 eu (v)

 yes (extension_type = = 1) {

 dependency_id [i]

 eu (v)

 quality_id [i]

 eu (v)

 num_directly_dependent_layers [i]

 eu (v)

 for (j = 0; j <num_directly_dependency_layers [i]; j ++)

 delta_reference_layer_id_minus1 [i] [j]

 eu (v)

 }

 }

 nu m_short_term_ref_pic_sets

 eu (v)

 for (i = 0; i <num_short_term_ref_pic_sets; i ++)

 short_term_ref_pic_set (i)

 yes (extension_type = = 0)

 view_dependency ()

 num_additional_profiles_levels_minus1

 eu (v)

 for (i = 0; i <= num_additional_profiles_levels_minus1; i ++) {

 additional_profile_idc [i]

 u (8)

 additional_reserved_zero_8bits [i] / * equal to 0 * /

 u (8)

 additional_level_idc [i]

 u (8)

 num_applicable_operation_points_minus1 [i]

 eu (v)

 for (j = 0; j <= num_applicable_operation_points [i]; j ++) {

5

10

fifteen

twenty

25

30

35

 temporary_id [i] [j]

 eu (v)

 layer_id [i] [j]

 eu (v)

 yes (extension_type = = 0) {/ * Always true for 3DV * /

 depth_included_flag

 u (1)

 num_target_output_views_minus1 [i] [j]

 eu (v)

 for (k = 0; k <num target output views minus1 [i] [j]; k ++)

 layer_id [i] [j] [k]

 eu (v)

 }

 if not (extension_type = = 1)

 layer_id [i] [j]

 eu (v)

 }

 }

 vps_vu i_para mete rs_p resent_flag

 u (1)

 yes (vps_vui_parameters_present_flag)

 vps_vui_parameters ()

 vps_extension_flag

 u (1)

 yes (vps_extension_flag)

 while (more_rbsp_data ())

 vps_exte nsion_d ata_fl a g

 u (1)

 rbsp_trailing_bits ()

 }

Examples of the semantics for the syntax of the video parameter set in Table 5 are discussed below. In general, similarly named syntactic elements that are not analyzed below may have the same semantics as discussed above with respect to Table 2. The semantics for the other syntactic elements may be as follows:

In this example, bit_equal_to_one is equal to 1 (that is, a binary value "1").

In this example, extention_type equal to 0 indicates that there may be multivist layers in the bit stream. In this example, extension_type equal to 1 specifies that several layers of dependency and / or quality may be present in the bit stream.

In this example, num_rep_formats_minus1 plus 1 specifies the maximum number of representation formats of different sets compatible with this set of video parameters; A representation format includes the bit depth and chroma format (that is, the value sets of bit_depth_luma_minus8, bit_depth_chroma_minus8 and chroma_format_idc), information on image resolution and the crop window in the encoded video sequence. The value of num_rep_formats_minus1 can be in the range between 0 and X, inclusive. Video encoder 20 and video decoder 30 can encode the bit depth set and chroma format for the base layer by bit_depth_luma_minus8, bit_depth_chroma_minus8 and chroma_format_idc and the bit depth and chroma format sets are signaled for layers of enhance using the following set of syntactic elements bit_depth_luma_minus8 [i], bit_depth_chroma_minus8 [i] and chroma_format_idc [i].

The video encoder 20 and the video decoder 30 can encode the first set of rendering format by samples bit_depth_luma_minus8, bit_depth_chroma_minus8, chroma_format_idc, pic_width_in_luma, pic_height_in_luma_samples, pic_cropping_flag_ piccropset_ piccropset_ piccropset_ piccropset_ piccropset_ piccropset_ piccropset_ pic_roprop_pict_program_set_program_set_pict_program_set_pict_program_set_program_set_pict_program_set_process_picture

In this example, bit_depth_luma_minus8 i], bit_depth_chroma_minus8 [i] and chroma_format_idc [i] specify, respectively, the i-th set of values bit_depth_luma_minus8, bit_depth_chroma_minus8 and chroma_format_idc encoded in the sequence of video.

In this example, pic_width_in_luma_samples [i] and

pic_height_in_luma_samples [i] specify, respectively, the width and height of each decoded image in luma sample units using the ith representation format.

5

10

fifteen

twenty

25

30

35

40

In this example, pic_cropping_flag [i] pic_crop_left_offset [i], pic_crop_right_offset [i], pic_crop_top_offset [i] and pic_crop_bottom_offset [i] specify, for the ith set of rendering format, the samples of the images in the video sequence encoded that are emitted from the decoding process, in terms of a rectangular region specified in image coordinates for the output.

In this example, rep_format_idx [i] specifies the value index for the additional bit depth set and chroma format that is applied to the layer with layer_id equal to i. The values of bit_depth_luma_minus8, bit_depth_chroma_minus8 and chroma_format_idc for the layer with layer_id equal to i can be equal to bit_depth_luma_minus8 [rep_format_idx [i]], bit_depth_chroma_minus8 [rep_format_ida] The value of rep_format_idx [i] will be in the range between 0 and X, inclusive.

In this example, dependency_id [i] specifies a dependency identifier for the layer with layer_id equal to i. dependency_id [i] can be in the range of 0 to X inclusive. When not present, it can be inferred that dependency_id [i] which is 0. When num_directly_dependent_layers [i] is greater than 0, dependency_id [i] can be equal to or greater than the dependency identifier of any layer on which the layer depends with layer_id equal to i.

In this example, quality_id [i] specifies an equality identifier for the layer with layer_id equal to i. quality_id [i] can be in the range of 0 to X inclusive. When not present, it can be inferred that quality_id [i] is 0. When num_directly_dependent_layers [i] is greater than 0, quality_id [i] can be equal to or greater than the quality identifier of any layer on which the layer depends on layer_id equal to and that has a dependency identifier equal to dependency_id [i].

In this example, num_short_term_ref_pic_sets specifies the number of short-term reference image sets that are specified in the video parameter set. The value of num_short_term_ref_pic_sets can be in the range between 0 and 64, inclusive.

In this example, depth_included_flag equal to 1 indicates that the current 3DV operating point contains depth. In this example, depth_included_flag equal to 0 indicates that the current 3DV operating point does not contain depth.

The sample syntax for the view dependency element of Table 5 is provided in the following Table 6:

TABLE 6

 view_dependency () {

 num_views_minus1

 eu (v)

 for (i = 0; i <= num_views_minus1; i ++)

 view_id [i]

 eu (v)

 for (i = 1; i <= num_views_minus1; i ++) {

 num_ref_views [i]

 for (j = 0; j <num ref views [i]; j ++)

 ref_view_idx [i] [j]

 eu (v)

 inter_view_texture_flag [i] [j]

 u (1)

 }

 }

 }

Table 7 below defines an example of a data set in which the view dependency of each non-basic view is directly signaled at the sequence level.

TABLE 7

 for (i = 1; i <= num views minus1; i ++) {

 num_ref_views [i]

 eu (v)

 for (j = 0; j <num ref views [i]; j ++ ______) _____________________________

 ref_view_idx [i] [j]

 eu (v)

 }

In this example, num_ref_views [i] specifies the number of view components for the prediction between views in the initial reference image list RefPicListO and RefPicListl in the decoding view components with view order index equal to i. In this example, the value of num_ref_views [i] is not greater than Min (15, 5 num_views_minus1). In this example, the value of num_ref_views [0] is equal to 0.

In this example, ref_view_idx [i] [j] specifies the view order index of the jth view component for prediction between views in the initial reference image list RefPicListO and RefPicListl in decoding a view component with order of view index equal to i. In this example, the value of ref_view_idx [i] [j] is in the range of 0 to 31, inclusive.

fifteen

As indicated above, a particular type of NAL unit (for example, type of NAL unit 10) can be used to encapsulate a set of video parameters. The syntax of the NAL unit can be modified as shown in the example in Table 8 below.

TABLE 8

 nal_unit (NumBytesInNALunit) {

 Descriptor

 forbidden_zero_bit

 f (1)

 nal_ref_flag

 u (1)

 nal_unit_type

 u (6)

 NumBytesInRBSP = 0

 nalUnitHeaderBytes = 1

 yes (nal_unit_type! = 10) {// no VPS NAL unit

 yes (cnt_p> 1)

 priority id

 u (v)

 yes (cnt_t> 1)

 temporary_id

 u (v)

 reserved_one_bit

 u (1)

 yes (cnt_d> 1)

 dependency_id

 u (v)

 yes (cnt_q> 1)

 quality_id

 u (v)

 reserved_one_bit

 u (1)

 yes (cnt_v> 1)

 view_idx

 u (v)

 yes (cnt_f)

 reserved_flags

 u (v)

 m = Ceil (log2 (cnt_p)) + Ceil (log2 (cnt_t)) + Ceil (log2 (cnt_d)) + Ceil (log2 (cnt_q)) + Ceil (log2 (cnt v)) + cnt f + 2

 yes (((m + 7 >> 3) << 3) - m)

 reserved bits

 u (v)

 nalUnitHeaderBytes + = ((m + 7) >> 3)

 }

 for (i = nalUnitHeaderBytes; i <NumBytesInNALunit; i ++) {

 yes (i + 2 <NumBytesInNALunit && next_bits (24) = = 0x000003) {

 rbsp_byte [NumBytesInRBSP ++]

 b (8)

 rbsp_byte [NumBytesInRBSP ++]

 b (8)

 i + = 2

5

10

fifteen

twenty

25

30

35

 emulation_prevention_three_byte / * equal to 0x03 * /

 f (8)

 if not

 rbsp_byte [NumBytesInRBSP ++]

 b (8)

 }

 }

In this example, elements are added within the instruction "yes (nal_unit_type! = 10)", in relation to the syntax of the conventional NAL unit. In this example, the number of bits used to flag the priority_id, temporal_id, dependency_id, quality_id and view_idx syntactic elements is Ceil (log2 (cnt_p)), Ceil (log2 (cnt_t)), Ceil (log2 (cnt_d)), Ceil ( log2 (cnt_q)) and Ceil (log2 (cnt_v)), respectively. Similarly, in this example, when any of the priority_id, temporal_id, dependency_id, quality_id and view_idx syntactic elements is not present, it follows that the value of that syntactic element is equal to 0.

Except as defined above with respect to the number of bits and inferences that can be drawn, the semantics for the syntactic elements of Table 8 can be defined as follows. The semantics of priority_id, dependency_id and quality_id can be as defined in the SVC extension of ITU-T H.264 / AVC. The semantic of temporary_id can be as defined in WD4 of HEVC. In this example, reserved_one_bit is equal to 1. The value 0 for reserved_one_bit can be specified by future extensions of the HEVC standard. Decoders, such as video decoder 30, can be configured to ignore the value of reserved_one_bit.

In this example, view_idx specifies the view order index for a view. The view_idx semantics can be the same as the "view order index" syntactic element as specified in the MVC extension of ITU-T H.264 / AVC.

In this example, each bit of reserved_flags is equal to 1. Other values for reserved_flags may be specified by future extensions of the next HEVC standard. Decoders, such as video decoder 30, can be configured to ignore the value of reserved_flags, unless they are configured to operate according to an extension that allocates semantically to bits of reserved_flags. In this example, the number of bits used to represent reserved_flags is reserved_flags_len.

In this example, each bit of reserved_bits is equal to 1. Other values for reserved_bits can be specified by the future extension of the next HEVC standard. The decoders, such as video decoder 30, can be configured to ignore the value of reserved_bits, again unless they are configured according to such future expansion. The number of bits used to represent reserved_bits, in this example, is ((m + 7 >> 3) << 3) -m.

Table 9 below provides an example syntax for a set of layer parameters. The same syntax can be used for each of the LPS of FIG. 5, in some examples.

TABLE 9

 layer_para_set () {

 Descriptor

 depth_flag

 u (1)

 layer_para_set_id

 eu (v)

 vps_id

 eu (v)

 // cu hierarchy {{

 log2_min_coding_block_size_minus3

 eu (v)

 log2_diff_max_min_coding_block_size

 eu (v)

 log2_min_transform_block_size_minus2

 eu (v)

 log2_diff_max_min_transform_block_size

 eu (v)

 log2_min_pcm_coding_block_size_minus3

 eu (v)

 max_transform_hierarchy_depth_inter

 eu (v)

 max_transform_hierarchy_depth_intra

 eu (v)

 // hierarchy of cu}}

 pcm_bit_depth_luma_minus1

 u (4)

5

10

fifteen

twenty

25

 pcm_bit_depth_chroma_minus1

 u (4)

 loop_filter_across_slice_flag

 u (1)

 sample_adaptive_offset_enabled_flag

 u (1)

 adaptive_loop_filter_enabled_flag

 u (1)

 pcm_loop_filter_disable_flag

 u (1)

 cu_qp_delta_enabled_flag

 u (1)

 // components

 num_tile_columns_minus1

 eu (v)

 num_tile_rows_minus1

 eu (v)

 yes (num_tile_columns_minus1! = 0 || num_tile_rows_minus1 0) {

 tile_boundary_independence_idc

 u (1)

 uniform_spacing_idc

 u (1)

 yes (uniform_spacing_idc! = 1) {

 for (i = 0; i <num_tile_columns_minus1; i ++)

 column width [i]

 eu (v)

 for (i = 0; i <num_tile_rows_minus1; i ++)

 row_height [i]

 eu (v)

 }

 }

 lps_extension_flag

 u (1)

 yes (lps_extension_flag)

 while (more_rbsp_data ())

 lps_exte nsion_d ata_fl ag

 u (1)

 rbsp_trailing_bits ()

 }

Examples of the semantics for the LPS syntax in Table 9 are described below. Different layers (for example, different views in MVC or different layers in SVC) may refer to different LPS. Different quality layers in the same dependency layer can share the same LPS. Different temporary layers in the same dependency layer can share the same LPS. Alternatively, different views may refer to the same LPS and different dependency layers may refer to the same LPS.

In this example, depth_flag equal to 1 specifies that the LPS is applied to the depth representations identified by the values of temporal_id, dependency_id, quality_id and view_idx of the LPS NAL unit. Depth_flag equal to 0 specifies that the LPS applies to texture representations identified by the values of temporal_id, dependency_id, quality_id and view_idx of the LPS NAL unit.

In this example, layer_para_set_id specifies the id of the current layer parameter set (LPS). Different sets of layer parameters with the same dependency_id and view_idx values, respectively, share a value space for layer_para_set_id, which means that different LPS with different combinations of depencey_id and view_idx can have the same value of layer_para_set_id.

Alternatively, all LPS can share the space of a value, which means that each LPS has a different value than layer_para_set_id.

In this example, vps_id identifies the set of video parameters to which this set of layer parameters refers.

In this example, lps_extension_flag equal to 0 specifies that there are no lps_extension_data_flag syntax elements present in the RBSP syntax structure of the layer parameter set. In this example, lps_extension_flag can be equal to 0 in bit streams that conform to the next HEVC standard. The value 1 for

5

10

fifteen

twenty

25

30

35

lps_extension_flag is reserved for future use by ITU-T | ISO / IEC Decoders, such as video decoder 30, can ignore all data that follows the value 1 for lps_extension_flag in a NAL unit of layer parameter set.

In this example, lps_extension_data_flag can have any value and does not affect compliance with the profiles specified in the next HEVC standard.

Other syntactic elements may have the same semantics as the syntactic elements with the same names in the SPS of the HEVC WD, but applying only to the images that refer to this LPS.

An LPS can be contained in a NAL unit whose header can be defined in accordance with Table 8 above. The following syntactic elements have the following slightly modified semantics when associated with an LPS.

In this example, priority_id is equal to the minimum value of the priority_id values of all NAL units that refer to this LPS.

In this example, temporal_id is equal to the minimum value of temporal_id of all NAL units that refer to this LPS.

In this example, dependency_id is equal to the dependency_id of all NAL units that refer to this LPS.

In this example, quality_id is equal to the minimum value of quality_id of all NAL units that refer to this LPS.

In this example, v_idx is the view index of the current LPS. All images that refer to this LPS can have a view id of view_id [v_idx].

Alternatively, the above syntactic elements can be directly signaled in the syntax table of the layer parameter set, as shown in the example in Table 10. A more detailed syntax table can be designed in accordance with Table 9 below. . In this case, these syntactic elements are not in the NAL unit header of the LPS and the analysis of the LPS may depend on the VPS with an ID equal to vps_id.

TABLE 10

 layer_para_set () {

 Descriptor

 vps_id

 u (8)

 yes (cnt_p> 1)

 priority_id

 u (v)

 yes (cnt_t> 1)

 temporary_id

 u (v)

 reserved_one_bit

 u (1)

 yes (cnt_d> 1)

 dependency_id

 u (v)

 yes (cnt_q> 1)

 quality_id

 u (v)

 yes (cnt_v> 1)

 view_idx

 u (v)

 depth_flag

 u (1)

 layer_para_set_id

 eu (v)

 // hierarchy of cu {{

 rbsp_trailing_bits ()

 }

An LPS, in this case, does not need to have a NAL unit header duplicating the previous syntactic elements. Assuming that the type of NAL unit of an NAL unit that encapsulates an LPS is, for example, 5, the

NAL unit header syntax can be modified slightly as shown in Table 11, which adds the exception "&& nal_unit_type! = 5" in the "if" instruction of Table 8:

5

TABLE 11

 nal_unit (NumBytesInNALunit) {

 Descriptor

 forbidden_zero_bit

 f (1)

 nal_ref_flag

 u (1)

 nal_unit_type

 u (6)

 NumBytesInRBSP = 0

 nalUnitHeaderBytes = 1

 yes (nal_unit_type! = 10 && nal_unit_type! = 5) {// no VPS NAL unit

 yes (cnt_p> 1)

 priority_id

 u (v)

 yes (cnt_t> 1)

 temporary_id

 u (v)

 reserved_one_bit

 u (1)

 yes (cnt_d> 1)

 dependency_id

 u (v)

 yes (cnt_q> 1)

 quality_id

 u (v)

 reserved_one_bit

 u (1)

 yes (cnt_v> 1)

 view_idx

 u (v)

 yes (cnt_f)

 reserved_flags

 u (v)

 m = Ceil (log2 (cnt_p)) + Ceil (log2 (cnt_t)) + Ceil (log2 (cnt_d)) + Ceil (log2 (cnt_q)) + Ceil (log2 (cnt v)) + cnt f + 2

 yes (((m + 7 >> 3) << 3) - m)

 reserved_bits

 u (v)

 nalUnitHeaderBytes + = ((m + 7) >> 3)

 }

 for (i = nalUnitHeaderBytes; i <NumBytesInNALunit; i ++) {

 yes (i + 2 <NumBytesInNALunit && next_bits (24) = = 0x000003) {

 rbsp_byte [NumBytesInRBSP ++]

 b (8)

 rbsp_byte [NumBytesInRBSP ++]

 b (8)

 i + = 2

 emulation_prevention_three_byte / * equal to 0x03 * /

 f (8)

 } if not

 rbsp_byte [NumBytesInRBSP ++]

 b (8)

 }

 }

In other examples, video encoder 20 and video decoder 30 can encode syntactic elements related to scalable features using fixed length encoding, as shown in the example in Table 12 below.

TABLE 12

layer_para_set () {

Descriptor

5

10

fifteen

twenty

25

30

35

 vps_id

 u (8)

 priority_id

 u (5)

 temporary_id

 u (3)

 dependency_id

 u (3)

 quality_id

 u (3)

 view_idx

 u (8)

 layer_para_set_id

 eu (v)

 // hierarchy of cu {{

Table 13 below provides an example of syntax for a set of image parameters (PPS) according to the techniques of this disclosure. In this example, the image parameter set does not need to signal a "seq_parameter_set_id", contrary to the conventional HEVC PPS.

TABLE 13

 pic_parameter_set_rbsp () {

 Descriptor

 pic_parameter_set_id

 eu (v)

 pps_extension_flag

 u (1)

 yes (pps_extension_flag)

 while (more_rbsp_data ())

 pps_extens ion_d ata_fl ag

 u (1)

 rbsp_trailing_bits ()

 }

Examples of semantics for the PPS in Table 13 are described below.

In this example, pps_extension_flag equal to 0 specifies that there are no pps_extension_data_flag syntax elements present in the RBSP syntax structure of the image parameter set. In this example, pps_extension_flag is equal to 0 in bit streams that meet the next HEVC standard. The value 1 for pps_extension_flag is reserved for future use by ITU-T | ISO / IEC Decoders, such as video decoder 30, can ignore all data that follows the value 1 for pps_extension_flag in a NAL unit of the image parameter set.

In this example, pps_extension_data_flag can have any value. It does not necessarily affect compliance with the profiles specified in the next HEVC standard. The semantics for pps_extension_data_flag values can be assigned in further developments of the HEVC standard or extensions of the standard without conflict with the techniques of this disclosure.

In the techniques of this disclosure, it is not necessary to indicate in the PPS any id of the set of sequence parameters or id of the set of layer parameters. Some other syntactic elements in PPS can be moved to LPS. That is, video encoder 20 and / or video decoder 30 can be configured to encode one or more LPS including data similar to the syntactic elements shown in Table 13.

FIG. 6 is a conceptual diagram illustrating an example of a set of grouping parameters (GPS) and GPS relationships with other sets of parameters and fragment headers. In this example, the other sets of parameters include LPS, SPS, PPS, adaptation parameter sets (APS) of type 0 (for example, APS that indicate adaptive loop filter parameters (ALF)), APS of type 1 ( for example, APS that indicates a quantization matrix) and other sets of parameters. In this example, the GPS includes a plurality of different groups, each of which has a unique GPS ID (also called group ID), in which each group indicates a particular one of each of the various parameter sets by the ID of a set of parameters. In this way, fragment headers only need to specify a group_id to specify each of the parameter sets corresponding to the group that has that group_id.

Tables 14 and 15 below provide alternative examples of syntax for a set of RBSP grouping parameters.

5

TABLE 14

 group_para_set_rbsp () {

 Descriptor

 number signaled_para_set_groups_minus1

 eu (v)

 for (i = 0; i <= number signaled for set groups minus1; i ++) {

 para_set_group_id [i]

 eu (v)

 lps_id [i]

 eu (v)

 pps_id [i]

 eu (v)

 for (j = 0; j <numParaSetTypes; j ++)

 para_set_type_id [i] [j]

 }

 gps_exte nsion_flag

 u (1)

 yes (gps_extension_flag)

 while (more_rbsp_data ())

 gps_exte nsion_d ata_fl ag

 u (1)

 rbsp_trailing_bits ()

 }

TABLE 15

 group_para_set_rbsp () {

 Descriptor

 number_signaled_para set_groups_minus1

 eu (v)

 for (i = 0; i <= number signaled for set groups minus1; i ++) {

 para_set_roup_id [i]

 eu (v)

 lps_id [i]

 eu (v)

 pps_id [i]

 eu (v)

 aps_id [i]

 eu (v)

 }

 gps_exte nsion_flag

 u (1)

 yes (gps_extension_flag)

 while (more_rbsp_data ())

 gps_exte nsion_d ata_fl ag

 u (1)

 rbsp_trailing_bits ()

 }

10 Video encoders, such as video encoder 20 and video decoder 30, can be configured to encode a set of grouping parameters according to, for example, Table 14 or Table 15. Examples are given below. of semantics for the syntax of the grouping parameter sets.

15 In this example, number_signalled_para_set_groups_minus1 plus 1 specifies the number of groups of flagged parameters. This value can be in the range between 0 and 30, inclusive.

In this example, para_set_group_id [i] specifies the ID of the ith set group of set parameters. The value of para_set_group_id [i] will be in the range between 0 and 31, inclusive.

In this example, para_set_type_id [i] [j] specifies the ID of the jth type of the parameter set for the i-th

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

group of parameter sets.

In this example, lps_id [i] indicates the id of the layer parameter set referenced by the group of parameter sets with a group id of para_set_group_id [i]. The dependency_id and view_idx values of an LPS with layer_para_set_id equal to lps_id [i] can be identical to the dependency_id and view_idx values, respectively, of the NAL unit of the parameter set group.

The dependency_id and view_idx values of a set of RBSP parameters are present in the NAL unit header of this RBSP in the examples in Tables 14 and 15 and the dependency_id and view_idx values of an LPS may be present in the unit header NAL of this LPS or in the LPS syntax table.

Alternatively, the dependency_id and view_idx values of an LPS with layer_para_set_id equal to lps_id [i] may not be identical to the dependency_id and view_idx values, respectively, of the NAL unit of the parameter set group.

In this example, pps_id [i] indicates the id of the image parameter set referenced by the parameter set group with a group id of para_set_group_id [i].

In this example, aps_id [i] indicates the id of the adaptation parameter set referenced by the parameter set group with a group id of para_set_group_id [i].

In this example, gps_extension_flag equal to 0 specifies that there are no gps_extension_data_flag syntax elements present in the RBSP syntax structure of the parameter set pool. Gps_extension_flag can be equal to 0 in bit streams that meet the next HEVC standard. The value 1 for gps_extension_flag may be reserved for future use by ITU-T | ISO / IEC Decoders, such as video decoder 30, can ignore all data that follows the value 1 for gps_extension_flag in the NAL unit of the parameter set pool. In general, gps_extension_data_flag can have any value. It does not have to affect compliance with the profiles specified in the next HEVC standard.

In some examples, para_set_type_id [i] [j] may instead be aps_id [i] [j], with similar semantics aaps_id [i] as described above.

As shown in FIG. 6, instead of referring to the ID of the set of image parameters in the fragment header, according to the techniques of this disclosure, the fragment header may refer to an ID of the group of parameter sets, indirectly referring to a LPS, a PPS and an APS of each type (for example, APS that provide ALF parameters and quantization matrices).

A video encoder can activate a set of video parameters or sets of layer parameters when a VCL NAL unit (containing a coded fragment) refers to the set of parameters, indirectly, for example, based on the design principle H .264 / AVC.

In some examples, parameter sets can be activated by a specific type of NAL unit instead of by an encoded fragment. For example, a specific type of NAL unit (parameter set activation NAL unit), if present in the bit stream, can activate one and exactly one, VPS. In several alternatives, moreover, such a NAL unit can activate at least one LPS. In addition, said type of NAL unit can activate at least one PPS. In addition, said type of NAL unit can activate at least one APS. An NAL unit of parameter set activation may be a set of RBSP grouping parameters. A NAL parameter set activation unit (PSA) may be applicable to an encoded video sequence. A PSA NAL unit can be considered a non-VCL NAL unit, that is, it is not directly relevant to a video encoder. The NAL unit header syntax of the PSA NAL unit can be the same as a VAL NAL unit.

In some examples, a PSA NAL unit, if present in an access unit, may precede the first VAL NAL unit of the access unit. There may be at least one PSA NAL unit in the first access unit of an encoded video sequence, for example, an IDR image. Multiple PSA NAL units in the same encoded video stream may contain the same VPS id; therefore, it is not necessary to activate different sets of video parameters within the same encoded video sequence. A PSA NAL unit, if present in an access unit, can precede any LPS, PPS, APS or SEI NAL unit, if present. A VPS NAL unit, if present in an access unit, can precede any LPS, PPS, APS or SEI NAL unit, if present. In several alternatives, in addition, a PSA NAL unit, if present in an access unit, may precede a VPS NAL unit, if present.

In some examples, video encoders, such as video encoder 20 and video decoder 30, can be configured to use the syntax of Table 16 for a set of sequence parameters (SPS), as opposed to SPS syntax conventional of, for example, the HEVC.

ze

 A

 Beu-; u3S3jd-s3! D ~ (3J-iLiJ3i.-Buo |

 (A

 Be u-p31 q e u 3- ^ xt> -j 3 ^ u |

 (0 = = £ snu! LU_0Z! S_> joo | q_6Lupoo_u! LU_2: 6o |) | s

 (A

 BBU-6uqs3U-p! - | BJodLU3i

 (A

 6e | j-3 | qes! P-J3iiw-doo | -iuod

 (6e | i_p0 | qeu0_Luod) | s

 (A

 Be | i-ao j | s-u! -i0oo-i | b

 (6B | i_p0 | qeu0_j0im_doo | _0AqdepB) | s

 (A

 BB | i_p3 | qBU3_J3J |! I_doO | _3A! JdBpB

 A

 Bb u-p01 qB u 0-i0sy o-0A qd b pB-0 | d lu b s

 (A

 BB | i_p0 | qBU3_30jjpBnb_3JBnbs_uou

 (A

 BB | i-p0 | qBU0-suoq! ^ IBd_uoqoLU-oui0LULuAsB

 (A

 BBU-p0 | qBU0-s0O! | S-ssojoB-j0im-doo | -b0s

 (A

 BBU-p0 | qBU0-sdB_U! -J0im-Bu!> | Oo | q0p

 A

 BBU-p0 | qBU0_BLun | -LuoJi-p0jd-BLUojqo

 BBy-0 | qBU0-iS! | -Bu! | BOS

 (A) in

 EJ} U! -Q} d3p-Aq3JEJ3! Q-iujojsuEJ} -XEiu

 (A) in

 J3jU! _Qjd0p_AqojBJ3! Q_LUJO: isuBJj_XBLU

 {

 (A) in

 0Z! S-> | oo | q-Bu! Poo-LUod-U! LU-XBLU-y! P-3Bo |

 (A) in

 gsnu! LU-0Z! s-> | oo | q-Bu! poo-Luod-u! LU-3Bo |

 } (6B | i_p0 | qBU0_LUod) | s

 (A) in

 3Z! S_> | 30 | q_lUJ0JSUEJ} _U! LU_XElU_.y! P_260 |

 (A) in

 3snu! LU-0Z! S-> | oo | q-LUJOisuBJi-u! LU-3Bo |

 (A) in

 3Z | s_> | oo | q_Bu! Poo_u! LU_XBLU_: y! P_2Bo |

 (A) in

 gsnu! LU-0Z! S-> | oo | q-Bu! poo-U! LU-3Bo |

 (A

 BBU-iU0S0jd-uoqBoy! PoLU-siS! |

 (6B |.} _ S} S! | _3! D _.} 0J_p0} 3LqS0J) | S

 A

 BB | i_sjS! | _O! D_i3J_p0jO! JjS3J

 {

 (A) in

 [| ] j0sb0jou! -Aou01b | -xblu

 (A) in

 [| ] so! d-j0pjo0j-Lunu

 (A) in

 [| ] BuN0ijnq-o! D-o0p-XBLU

 } (++ | 1 |, snu! Iu — sjbAbi- | BJodiu0} —XBiu => \ lo = \) BJBd

 (A) in

 ^ snu! LU-qs | -iuo-j0pjo-o! d-XELU-3Bo |

 (A

 BBU-ssBdAq-iuBnbsuBJi_oj0z-A-0Luuddb

 {

 (fr) n

 |, snu! LU-BLUOjqo-qid0p-i! q-LUod

 (fr) n

 |, snu! LU-BLun | -qid0p-i! q-Luod

 } (6B | i_p0 | qBU0_LUod) | s

 A

 Be y-p0 | q b u 0-lu od

 (A) in

 xpj-JBLUJO ^ -d0J

 (A) in

 P! _J0S_J0J0LUBJBd — O0pjA

 jojduosaQ

 } () B! Ou0no0s_0p_soJi0LUBJBd_0p_ojunruoo_0p_dsqj

91. vnavi

zuos-zo-eu

sesoozei.3

 tiles_or_entropy_coding_sync_idc

 u (2)

 yes (tiles_or_entropy_coding_sync_idc = = 1) {

 num_tile_columns_minus1

 eu (v)

 num_tile_rows_minus1

 eu (v)

 uniform_spacing_flag

 u (1)

 yes (! uniform_spacing_flag) {

 for (i = 0; i <num_tile_columns_minus1; i ++)

 column_width [i]

 eu (v)

 for (i = 0; i <num_tile_rows_minus1; i ++)

 row_height [i]

 eu (v)

 }

 loop_filter_ac ross_ti les_e nabled_flag

 u (1)

 }

 vui_parameters_present_flag

 u (1)

 yes (vui_parameters_present_flag)

 vui_parameters ()

 sps_extension_flag

 u (1)

 yes (sps_extension_flag)

 while (more_rbsp_data ())

 s ps_exte nsion_d ata_fl ag

 u (1)

 rbsp_trailing_bits ()

 }

The SPS example of Table 16 removes profile_idc, reserved_zero_8bits, level_idc, chroma_format_idc, separate_colour_plane_flag and corresponding conditional "if" max_temporal_layers_minus1, pic_width_in_luma_samples, pic_height_in_luma_samples, pic_cropping_flag, pic_crop_left_offset, 5 pic_crop_right_offset, pic_crop_top_offset and pic_crop_bottom_offset and the corresponding conditional statement "if" bit_depth_luma_minus8, bit_depth_chroma_minus8, num_short_term_ref_pic_sets and short_term_ref_pic_set (i) and the corresponding conditional instruction "yes" of the conventional SPS syntax. In addition, the SPS example in Table 16 adds a video_parameter_set_id and rep_format_idx. The semantics for the remaining remaining syntactic elements may be the same as defined in the conventional HEVC. The semantics for the added elements 10 video_parameter_set_id and rep_format_idx can be defined as follows:

In this example, video_parameter_set_id identifies the set of video parameters (VPS) referenced by the current SPS. Alternatively, video_parameter_set_id does not need to be signaled and a GPS can be used to link an SPS to a specific VPS.

fifteen

In this example, rep_format_idx specifies the index of the representation format indicated in the set of video parameters referenced.

As another alternative, Table 17 provides another example of syntax for a set of 20 grouping parameters. It is assumed that, in this example, the syntactic element of the video parameter set ID is not present in the SPS syntax, as described above.

TABLE 17

 group_para_set_rbsp () {

 Descriptor

 gps_is

 eu (v)

 vps_id

 eu (v)

 sps_id

 eu (v)

 pps_id

 eu (v)

 nu m_ref_aps_ids

 eu (v)

5

10

fifteen

twenty

25

30

35

40

Four. Five

 for (i = 0; i <num ref aps ids; i ++) {

 ref_aps_id [i]

 eu (v)

 ref_aps_param_type [i]

 eu (v)

 }

 gps_exte nsion_flag

 u (1)

 yes (gps_extension_flag)

 while (more_rbsp_data ())

 g p s_exte nsion_d ata_fl a g

 u (1)

 rbsp_trailing_bits ()

 }

The semantics for the syntactic elements of Table 17 can be defined as follows:

In this example, gps_id specifies the identifier of a set of group parameters (GPS).

In this example, vps_id specifies the identifier of the set of video parameters referenced by GPS.

In this example, sps_id specifies the identifier of the sequence parameter set referenced by the GPS.

In this example, pps_id specifies the identifier of the set of image sequence parameters referenced by the GPS.

In this example, num_ref_aps_ids specifies the number of the following syntactic elements ref_aps_id [i]. The value of num_ref_aps_ids can be in the range between 0 and 4, inclusive.

In this example, ref_aps_id [i] identifies the ith set of adaptation parameters referenced by the group parameter set.

The same value of ref_aps_id [i] can be present in the loop more than once and, therefore, reference can be made to more than one type of APS parameters of the same APS by the same GPS and can be applied to the fragments encoded in relation to the GPS.

In this example, ref_aps_param_type [i] specifies the type of APS parameters included in the i-th set of adaptation parameters referenced by the group parameter set. The value of ref_aps_parame_type [i] can be in the range between 0 and 3, inclusive. Values from 0 to 3, inclusive, for ref_aps_parame_type [i] correspond to the APS parameter types of the scaling list, unblocking filter, sample adaptation deviation (SAO) and ALF, respectively. The values of ref_aps_parame_type [i] for any two values other than i will not be identical, in some examples.

In this example, gps_extension_flag equal to 0 specifies that there are no gps_extension_data_flag syntax elements present in the RBSP syntax structure for grouping the parameter set. gps_extension_flag can be equal to 0 in bit streams that comply with the next HEVC standard. The value 1 for gps_extension_flag may be reserved for future use by ITU-T | ISO / IEC Decoders, such as video decoder 30, can ignore all data that follows the value 1 for gps_extension_flag in the NAL unit of the parameter set pool.

In this example, gps_extension_data_flag can have any value. It does not have to affect compliance with the profiles specified in the next HEVC standard.

Video encoders, such as video encoder 20 and video decoder 30, can apply the following process to activate parameter sets for single-layer or single-view bit streams, when GPS is specified according with Table 17 or substantially conforms to the example in Table 17.

An RBSP of a set of adaptation parameters may include parameters to which the NAL units of encoded fragment of one or more images encoded through one or more sets of group parameters referred to by the NAL units of reference can indirectly refer to. coded fragment Each RBSP of a set of adaptation parameters may initially be considered non-active at the beginning of the

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

operation of the decoding process. At most one RBSP of a set of adaptation parameters can be considered active for each type of APS parameters at any given time during the operation of the decoding process, and the activation of any RBSP of a particular set of adaptation parameters for a particular type of APS parameters results in the deactivation of the RBSP of a set of previously active adaptation parameters (if any) for that particular type of APS parameters.

When an RBSP of a set of adaptation parameters (with a particular value of aps_id) is not active for a particular type of APS parameters and is referenced indirectly by a nAl fragment unit encoded for that particular type of APS parameters (using that value of aps_id) through a set of group parameters referenced by the encoded fragment NAL unit, can be activated for that particular type of APS parameters. This RBSP of the set of adaptation parameters is called RBSP of the set of active adaptation parameters for that particular type of APS parameters until it is deactivated by the activation of another RBSP of a set of adaptation parameters for that particular type of APS parameters. An RBSP of a set of adaptation parameters, with that particular value of aps_id, may be available for the decoding process before activation.

An RBSP of a set of image parameters may include parameters to which the encoded fragment NAL units of one or more encoded images may indirectly refer to through one or more sets of group parameters referred to by the NAL units of coded fragment Each RBSP of a set of image parameters may initially be considered active at the beginning of the decoding process operation. At most one RBSP of a set of image parameters can be considered active at any given time during the operation of the decoding process, and the activation of any RBSP of a set of specific image parameters results in the deactivation of the RBSP of a set of previously active image parameters (if any).

When an RBSP of a set of image parameters (with a particular value of pic_parameter_set_id) is not active and is referenced indirectly by a coded fragment NAL unit (using that pic_parameter_set_id value) through a set of group parameters referred to in part of the encoded fragment NAL unit, can be activated. This RBSP of a set of image parameters is called RBSP of the set of active image parameters until it is deactivated by activating another RBSP of a set of image parameters. An RBSP of a set of image parameters, with that particular value of pic_parameter_set_id, may be available for the decoding process before activation.

Any set of NAL image parameters that contain the value of pic_parameter_set_id for the active image parameter set RBSP for an encoded image can have the same content as that of the active image parameter set RBSP for the image encoded unless follow the last VCL NAL unit of the encoded image and precede the first VCL NAL unit of another encoded image.

An RBSP of a set of sequence parameters may include parameters to which the NAL units of encoded fragment of one or more images encoded through one or more sets of group parameters referred to by the NAL units of reference can indirectly refer to. encoded fragment or reference may be made thereto by one or more SEI NAL units containing a buffer storage SEI message. Each RBSP of a set of sequence parameters may initially be considered non-active at the beginning of the decoding process operation. At most one RBSP of a set of sequence parameters can be considered active at any given time during the operation of the decoding process, and the activation of any RBSP of a set of specific sequence parameters results in the deactivation of the RBSP of a set of previously active sequence parameters (if any).

When an RBSP of a set of sequence parameters (with a particular value of seq_parameter_set_id) is no longer active and is referenced indirectly by a coded fragment NAL unit through a set of group parameters to which refers to the encoded fragment NAL unit (using that value of seq_parameter_set_id) or referenced to it by a NAL SEI unit that contains a buffer storage SEI message (which uses that value of seq_parameter_set_id), can be activated This RBSP of the sequence parameter set is called RBSP of the active sequence parameter set until it is deactivated by activating another RBSP of a sequence parameter set. An RBSP of a set of sequence parameters, with that particular value of seq_parameter_set_id and contained within an access unit with temporary_id equal to 0, may be available for the decoding process before activation. An RBSP of a set of activated sequence parameters will remain active during the entire encoded video sequence.

An RBSP of a set of video parameters may include parameters to which the NAL units of encoded fragment of one or more images encoded through one or more sets of group parameters referred to by the NAL units of reference may refer indirectly. encoded fragment, or reference may be made thereto by one or more SEI NAL units containing a SEI message of

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

Intermediate storage period. Each RBSP of a set of video parameters may initially be considered non-active at the beginning of the decoding process operation. At most one RBSP of a set of video parameters can be considered active at any given time during the operation of the decoding process, and the activation of any RBSP of a set of specific video parameters results in the deactivation of the RBSP of a set of previously active video parameters (if any).

When an RBSP of a set of video parameters (with a particular value of video_parameter_set_id) is no longer active and is referenced indirectly by a coded fragment NAL unit through a set of group parameters to which refers to the encoded fragment NAL unit (using that video_parameter_set_id value) or referenced to it by a NAL SEI unit that contains an intermediate storage period SEI message (using that video_parameter_set_id value), can be activated . This RBSP of the video parameter set is called RBSP of the active video parameter set until it is deactivated by activating another RBSP of the video parameter set. An RBSP of a set of video parameters, with that particular value of video_parameter_set_id and contained within an access unit with temporary_id equal to 0, will be available for the decoding process before its activation. An RBSP of a set of activated video parameters will remain active during the entire encoded video sequence.

Any NAL unit of sequence parameter set that contains the value of seq_parameter_set_id for the RBSP of the active sequence parameter set for an encoded video sequence may have the same content as that of the RBSP of the active sequence parameter set for the encoded video sequence, unless it follows the last access unit of the encoded video sequence and precedes the first VCL NAL unit and the first NAL SEI unit that contains an intermediate storage period SEI message ( when present) from another encoded video stream.

Any NAL unit in the video parameter set that contains the value of video_parameter_set_id for the RBSP of the active video parameter set for an encoded video sequence can have the same content as that of the RBSP of active video parameter set for the encoded video stream, unless it follows the last access unit of the encoded video stream and can precede the first VCL NAL unit and the first NAL SEI unit that contains an intermediate storage period SEI message (when present) of another encoded video sequence.

All restrictions expressed in the relationship between the values of the syntactic elements (and the values of the variables derived from those syntactic elements) in video parameter sets, sequence parameter sets, image parameter sets and image sets adaptation parameters and other syntactic elements are expressions of restrictions that can be applied only to the sets of active video parameters, the set of active sequence parameters, the set of active image parameters and the set of active adaptation parameters for each type Particular of APS parameters. If there is any RBSP of a set of video parameters that is not activated in the bit stream, its syntactic elements may have values that conform to the specified restrictions if they were activated by reference in a bit stream that is otherwise set . If there is any RBSP of a set of sequence parameters that is not activated in the bit stream, its syntactic elements may have values that conform to the specified restrictions if they were activated by reference in a bit stream that is otherwise set . If there is any RBSP of a set of image parameters that is never activated in the bit stream, its syntactic elements may have values that conform to the specified constraints if they were activated by reference in a bit stream that fits another mode. If there is any adaptation parameter set RBSP that is never activated in the bit stream, its syntactic elements may have values that conform to the specified restrictions if they were activated by reference in a bit stream that is otherwise set .

During the operation of the decoding process, the values of the parameters of the set of active video parameters, the set of active sequence parameters, the set of active image parameters and the set of active adaptation parameters for each operation can be considered in effect type of APS parameters. For the interpretation of the SEI messages, the values of the parameters of the video parameter set, sequence parameter set, image parameter set and adaptation parameter set that are active for the operation of the process can be considered decoding for the VCL NAL units of the image encoded in the same access unit unless otherwise specified in the SEI message semantics.

FIG. 7 is a flowchart illustrating an example procedure for encoding video data in accordance with the techniques of this disclosure. Although described with respect to video encoder 20, it should be understood that other video encoding devices can be configured to perform the procedure of FIG. 7.

Initially, in this example, video encoder 20 receives a bit stream that includes one or more layers of raw video data (100). For example, video source 18 (FIG. 1) can provide video data

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

multivist to video encoder 20. Alternatively, video encoder 20, or a preprocessor thereof, can divide a stream of unprocessed video bits into a plurality of various layers, for example, spatial resolution layers, layers of quality, temporary layers or similar. In other examples, a bit stream can be divided into a combination of several layers, for example, any combination of views, spatial resolution layers, quality layers, time layers or the like.

The video encoder 20 can determine one or more common parameters for corresponding sequences between a set of layers (102). The corresponding sequences can be sequences that have corresponding temporal positions in different layers. That is, a first sequence, which has a start time (in terms of display time) of T1 and an end time (again in terms of display time) of T2, and a second sequence, which also has a T1 start time and a T2 end time, it can be said that they correspond to each other. In particular, the first sequence may be part of a first layer and the second sequence may be part of a different second layer. A "sequence" may include a series of consecutive images in decoding order, for example, beginning with an instant decoding update image (IDR) and ending immediately before a subsequent IDR image in the decoding order. In general, the parameters may correspond to a set of corresponding sequences of one or more layers, for example, N layers, where N is an integer. The video encoder 20 can then encode a VPS that includes data for the determined parameters (104). For example, video encoder 20 can encode a VPS corresponding to one of the examples in Table 2 or Table 5.

The video encoder 20 can also determine common parameters for a sequence within a layer (106). The sequence may comprise one of the sequences corresponding to other sequences in other layers for which the VPS was encoded. The video encoder 20 can encode a set of sequence parameters (SPS) that includes the common parameters for the sequence (108). Therefore, it should be understood that VPS and SPS are separate data structures and correspond to different types of video data. While a VPS may correspond to a set of corresponding sequences between a plurality of layers, the SPS corresponds to a sequence in one layer. The SPS can substantially conform to an SPS of H.264 / AVC, the SPS of H.264 / AVC extended by MVC (illustrated in Table 1 above), the next HEVC standard, or the example of Table 16 described above. In addition, video encoder 20 can encode a set of image parameters (PPS) for an image in the sequence (110). The PPS can substantially conform to an SPS of H.264 / AVC, the next HEVC standard, or the example in Table 13 described above. Although the procedure of FIG. 7 shows the coding of only one PPS, it should be understood that multiple PPS can be encoded. One or more images may refer to the same PPS.

The video encoder 20 can then determine if the recent layer for which an SPS was encoded and a PPS is the last layer (112). If the last layer has not yet been treated ("NO" branch of 112), video encoder 20 can select a next layer and encode an SPS and one or more PPS for the next layer, for example, according to the steps 106-110. After the last layer ("SI" branch of 112) has been treated, the video encoder 20 can encode video data of the various layers based on the VPS, SPS and PPS data. Various examples of encoding video data based, at least in part, on a VPS are described in more detail below with respect to FIGs. 9-12.

Although not shown in the example of FIG. 7, in some examples, video encoder 20 may additionally encode one or more LPS and / or one or more GPS, as described above. The LPS can substantially conform to the examples in Table 9, Table 10 or Table 12, while the GPS can substantially conform to the examples in Table 14, Table 15 or Table 17. In such examples, video encoder 20 encodes video data also based, at least in part, on LPS and / or GPS.

Thus, the procedure of FIG. 7 represents an example of a procedure that includes encoding a set of video parameters (VPS) for one or more layers of video data, in which each one or more layers of video data refers to the vPs, and encoding one or more layers of video data based, at least in part, on the VPS.

FIG. 8 is a flow chart illustrating an example of a video data decoding procedure according to the techniques of this disclosure. Although described with respect to video decoder 30, it should be understood that other video decoding devices can be configured to perform the procedure of FIG. 8.

Initially, video decoder 30 receives a bit stream that includes a VPS, one or more SPS, and one or more PPS for coded video data layers (120). The video decoder 30 can then decode the VPS, which includes common parameters for corresponding sequences between one or more layers (122). Similarly, video decoder 30 can decode a set of sequence parameters that includes common parameters for a single layer sequence (124). In addition, video decoder 30 can decode a set of image parameters that includes parameters for an image of the sequence (126). As discussed above, one or more images may refer to the same PPS and, therefore, the

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

PPS parameters can be considered common to one or more imageries. Similarly, video decoder 30 can decode a plurality of PPS for the sequence, although it is not shown in FIG. 8.

In addition, video decoder 30 can determine if the most recent layer was the last layer to be treated (128). If the most recent layer was not the last layer ("NO" branch of 128), the video decoder 30 may proceed to decode an SPS and one or more PPS for a subsequent layer according to steps 124 and 126. On the other On the other hand, if the most recent layer was the last layer ("YES" branch of 128), the video decoder 30 can proceed to decode video data of the layers based on the VPS, SPS and PPS (130). Examples of encoding video data based, at least in part, on a VPS are analyzed in greater detail with respect to FIGs. 9-12.

Although not shown in the example of FIG. 8, in some examples, video decoder 30 may additionally decode one or more LPS and / or one or more GPS, as described above. The LPS can substantially conform to the examples in Table 9, Table 10 or Table 12, while the GPS can substantially conform to the examples in Table 14, Table 15 or Table 17. In such examples, the video decoder 30 decodes video data also based, at least in part, on LPS and / or GPS.

Thus, the procedure of FIG. 8 represents an example of a procedure that includes encoding a set of video parameters (VPS) for one or more layers of video data, in which each one or more layers of video data refers to the VPS and encodes a or more layers of video data based at least in part on the VPS.

FIG. 9 is a flow chart illustrating an example of a video data encoding procedure based, at least in part, on a certain number of time layers as indicated in a VPS. The procedure of FIG. 9 can be performed by video encoder 20 and / or video decoder 30. For the purposes of the example, the procedure of FIG. 9 is described with respect to video decoder 30.

In this example, the video decoder 30 encodes (ie decodes) a VPS indicating a certain number of time layers in video data (150), for example, of one or more layers to which the VPS corresponds. For example, video decoder 30 can decode "cnt_t" as described with respect to Table 2 above. To mention another example, video decoder 30 can decode num_temporal_layers_minus1, as described with respect to Table 5 above.

Based on this indication, in this example, video decoder 30 decodes temporary identifiers for each of the time layers (152). Similarly, the video decoder 30 can determine the identifier values of the reference image based on the number of time layers (154). For example, video decoder 30 can be configured to determine that, for a current image in the N layer, the current image will not use images in or on the N + 1 layer as a reference. Therefore, video decoder 30 can determine identifiers for possible reference images in layers at or below layer N. In addition, video decoder 30 can decode image data in time layer N using reference data from layers to (and including) layer N (156). Therefore, FIG. 9 represents an example of a procedure that includes data coding of a VPS indicative of a maximum number of time layers in one or more video data layers and coding of one or more layers based, at least in part, on the VPS.

FIG. 10 is a flow chart illustrating an example of a video data coding procedure based, at least in part, on a certain number of images to be rearranged in one or more layers and images to be stored in a buffer of decoded images. The procedure of FIG. 10 can be performed by video encoder 20 and / or video decoder 30. For the purposes of the example, the procedure of FIG. 10 is described with respect to video decoder 30.

In this example, video decoder 30 decodes a VPS that indicates a certain number of images to be reordered in one or more layers of video data and a certain number of images to be stored in a buffer of decoded images (e.g., memory of reference images 82) at a given time (160). For example, video decoder 30 can decode a VPS syntactic element that substantially corresponds to num_reorder_pics as described with respect to Table 16 above and / or bitstream restriction information that specifies a DPB size. In other examples, the VPS could include only one or the other, and not necessarily both, of the number of images to be reordered and the number of images to be stored in the buffer of decoded images. The video decoder 30 can then manage the buffer of decoded images (for example, reference image memory 82) based on the number of images to be reordered and / or stored (162). For example, video decoder 30 can delete images from memory 82 of the reference image when more than the number of images to be stored in memory 82 of reference images is stored.

The video decoder 30 can also determine the identifier values of the reference image based on the number of images in the DPB (ie, in the reference image memory 82) (164). In addition, video decoder 30 can decode image data based on the values of

5

10

fifteen

twenty

25

30

35

40

Four. Five

fifty

55

60

65

reference image identifier (166). Thus, the procedure of FIG. 10 represents an example of a procedure that includes the encoding of data from a VPS indicative of a certain number of images to be stored in a decoded image buffer (DPB) during decoding of one or more layers and a procedure that includes encoding of data from a VPS indicative of a certain number of frames to be rearranged in at least one of one or more layers.

FIG. 11 is a flow chart illustrating an example of a video data encoding procedure based, at least in part, on hypothetical reference decoder (HRD) parameters set in a VPS. The procedure of FIG. 11 can be performed by video encoder 20 and / or video decoder 30. For the purposes of the example, the procedure of FIG. 11 is described with respect to video decoder 30.

In this example, video decoder 30 decodes a VPS indicating the HRD parameters (170). The video decoder 30 can additionally determine the extraction times for the images of an encoded image buffer (CPB) based on the HRD parameters (172). The video decoder 30 can then delete data from the CPB based on the determined elimination times (174), and decode the data deleted from the CPB. Similarly, the procedure of FIG. 11 represents an example of a procedure that includes data coding of a vPs indicative of one or more hypothetical reference decoder (HRD) parameters and data coding of one or more layers based on the HDR parameters.

FIG. 12 is a flowchart illustrating an example of a video data encoding procedure based, at least in part, on expansion data signaled in a VPS. The procedure of FIG. 12 can be performed by video encoder 20 and / or video decoder 30. For the purposes of the example, the procedure of FIG. 12 is described with respect to video decoder 30.

The video decoder 30, in this example, decodes data from a VPS indicating whether the VPS includes extension data (180). For example, video decoder 30 can decode a vps_extension_flag of the VPS. The video decoder 30 then determines whether the data indicates that the VPS includes extension data (182). If the data indicates that the VPS includes extension data ("SI" branch of 182), the video decoder 30 encodes VPS extension data for one or more extension coding tools (184) and decodes video data using the tools of extension coding and extension data 186). On the other hand, if the data indicates that the VPS does not include extension data ("NO" branch of 182), the video decoder 30 can decode the video data using conventional coding tools (188). Thus, the procedure of FIG. 12 represents an example of a procedure that includes data coding of a VPS indicative of whether the VPS includes an extension beyond a corresponding standard and when the VPS includes the extension, data for the extension, as well as video data coding based in the VPS extension data.

It should be recognized that, depending on the example, certain acts or events of any of the techniques described herein may be performed in a different sequence, may be added, merged or omitted altogether (for example, not all of the acts or events described are necessary for the implementation of the techniques). In addition, in certain examples, acts or events can be performed simultaneously, for example, by processing multiple threads, processing interrupts or multiple processors, rather than sequentially.

In one or more examples, the described functions can be implemented in hardware, software, firmware or any combination thereof. If implemented in software, functions, such as one or more instructions or code, can be stored in, or transmitted by, a computer-readable medium, and executed through a hardware-based processing unit. Computer readable media may include computer readable storage media, which correspond to a tangible media such as data storage media or communication media that include any media that facilitates the transfer of a computer program from one location to another, by example, according to a communication protocol. In this way, the computer-readable media can correspond, in general, to (1) tangible and computer-readable storage media, which are non-transient, or (2) a communication medium such as a signal or a carrier wave. The data storage means may be any available means that can be accessed from one or more computers or one or more processors to retrieve instructions, code and / or data structures to implement the techniques described in the present disclosure. A computer program product may include a computer readable medium.

By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory or any other other means that can be used to store the desired program code in the form of instructions or data structures and which can be accessed by a computer. In addition, any connection properly receives the name of computer readable media. For example, if the instructions are transmitted from a network headquarters, a server or other source

5

10

fifteen

twenty

25

30

35

40

remote using a coaxial cable, an optical fiber cable, a twisted pair, a digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwave, then the coaxial cable, the fiber optic cable, the twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of the medium. However, it should be understood that computer readable storage media and data storage media do not include connections, carrier waves, signals or other transient media, but instead are geared towards tangible non-transient storage media. The discs, as used herein, include the compact disc (CD), the laser disc, the optical disc, the digital versatile disc (DVD), the flexible disc and the Blu-ray disc, where some discs normally they reproduce data magnetically, while other discs reproduce the data optically with laser. Combinations of the above should also be included within the scope of computer readable media.

The instructions can be executed by one or more processors, such as one or more digital signal processors (DSP), general purpose microprocessors, application specific integrated circuits (ASIC), field programmable logic formations (FPGA) or others integrated or discrete logic circuits equivalent. Accordingly, the term "processor", as used herein, may refer to any previous structure or to any other structure suitable for the implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within specific hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. In addition, the techniques could be fully implemented in one or more circuits or logic elements.

In other examples, this disclosure contemplates a computer-readable medium comprising a data structure stored therein, in which the data structure includes an encoded bit stream consistent with this disclosure. In particular, the encoded bit stream may include one or more layers of video data and a video parameter (VPS) for the one or more layers of video data, in which each of the one or more layers of data Video refers to the VPS and one or more layers of video data are encoded based, at least in part, on the VPS.

The techniques of the present disclosure can be implemented in a wide variety of devices or devices, including a wireless telephone, an integrated circuit (IC) or a set of IC (for example, a chipset). In the present disclosure several components, modules or units are described to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require the realization by different hardware units. Rather, as described above, various units can be combined in a codec hardware unit, or provided by a collection of interoperable hardware units, including one or more processors, as described above, in conjunction with the software and / or appropriate firmware.

Various examples have been described. These and other examples are within the scope of the following claims.

Claims (9)

one. 5 10 15 20 2. 25 3. 30 35 Four. 40 Four. Five 5. fifty 55 60 65 6. A video data coding procedure, the procedure comprising: coding (104, 122) of a set of video parameters, VPS, for a plurality of layers of video data, in which each of the plurality of layers of video data refers to the VPS, and in which the VPS coding includes: VPS data coding indicative of a certain number of frames to be rearranged in at least one among the plurality of video data layers, VPS data encoding indicative of a certain number of images to be stored in a buffer of decoded images, DPB, during decoding of the plurality of video data layers, and VPS data coding indicative of a maximum number of time layers in the plurality of video data layers; Y encoding (114, 130) the plurality of layers of video data based, at least in part, on the VPS. The method according to claim 1, wherein the VPS coding further comprises at least one of: data coding of the VPS indicative of one or more sets of hypothetical reference decoders, HRD, parameters; or VPS data coding indicative of whether the VPS includes an extension beyond a corresponding standard, and when the VPS includes the extension, data for the extension. The method according to claim 1, wherein the encoding of the plurality of layers of video data comprises at least one of: encoding of the plurality of layers of video data according to the High Efficiency Video Coding, HEVC; or coding of the plurality of layers of video data according to, at least one among, Multivist Video Coding, MVC and Scalable Video Coding, SVC. The method according to claim 1, wherein encoding the VPS comprises encoding information that specifies, for one or more dimensions of the plurality of video data layers, one or more of a certain number of priority layers in the plurality of layers of video data, a certain number of dependency layers in the plurality of video data layers, a certain number of temporary layers in the plurality of video data layers, a maximum number of quality layers for any of the layers of dependence on the plurality of layers of video data and a maximum number of views on the plurality of layers of video data and, preferably, where when a subset of the plurality of layers of video data has the same spatial resolution and the same bit depth, each of the subset layers corresponds to a different one of the dependency layers. The method according to claim 4, wherein coding the VPS comprises encoding information defining an assignment of a sample index to a characteristic indicator, and wherein the coding of the information defining the assignment comprises at least one of: information coding that specifies a respective feature indicator for each of a plurality of feature indexes when a feature indicator that defines features of a dimension of the plurality of video data layers is not within a zero index range to a sample dimension counter minus 1 in which the counter is defined by an index; or encoding one or more of a respective spatial resolution for each of a plurality of dependency indices, a frame rate for each of a plurality of time indices, a view identifier for each of a plurality of view indices, a pair of specific depth values for luminance and chrominance for each of a plurality of bit depth indices, and a specific chrominance sampling format indicator for each of a plurality of chrominance sampling formats. The method according to claim 1, wherein encoding the VPS comprises encoding information defining control parameters and one or more tool enable / disable indicators and 7. 10 fifteen 20 8. 25 30 35 40 9. Four. Five fifty 10. 55 eleven. 60 12. 65 13. preferably, in which the control parameters and the one or more tool enable / disable indicators comprise one or more of pcm_bit_depth_luma_minus1, a pcm_bit_depth_chroma_minus1, a loop_filter_across_slice_flag, a pcm_loop_filter_disable_flag, a temporary_id_nesting_flag, one or more syntactic elements related to components, a chroma_pred_from_luma_enabled_flag, a sample_enptd_off adaptive_loop_filter_enabled_flag, and an inter_4x4_enabled_fla. The method according to claim 1, wherein encoding the VPS comprises encoding information defining one or more operating point descriptors and, preferably, in which encoding the information defining the one or more operating point descriptors comprises information of coding that defines one or more of a certain number of maximum operation points, dependence between different layers or views, profile and level for each of the operation points, for each operation point, operation code video coding layer , VCL, network abstraction layer, NAL, unit representation, for each dimension one or more of a specific index value, a range of possible index values for the dimension, and a list of index values, bit rate for each of the operation points, dependence between the operation points, restrictions for each of the operation points, video usability information, VUI, for each one of the operation points, and VUI for each of the plurality of layers of video data. The method according to claim 1, further comprising encoding a respective set of layer sequence parameters, LPS, for each of the plurality of video data layers, in which to encode the plurality of video data layers based on less in part in the VPS comprises encoding the plurality of layers of video data based at least in part on the VPS and the respective LPS and, preferably, on which the coding of the respective LPS for each of the plurality of data layers Video includes at least one of: information coding that defines a sample dimension indication that indicates, for each dimension, an index for each dimension; information coding that defines the control parameters and the tools enable / disable indicators and, preferably, in which the control parameters and the one or more tools enable / disable indicators comprise one or more of a pcm_bit_depth_luma_minus1, a pcm_bit_depth_chroma_minus1, a loop_filter_across_slice_flag, a pcm_loop_filter_disable_flag, one or more syntactic elements related to components, a chroma_pred_from_luma_enabled_flag, a sample_adaptive_offset_enabled_flag, a adaptive_loop_filter_enabled_flag, and an encoding unit, CU, hierarchy; or information coding that defines the information of one or more sets of different parameters that are applied to at least one of a fragment, a group of fragments, an image and several images that refer to a set of common image parameters, PPS. The method according to claim 1, further comprising encoding one or more sets of image parameters, PPS such that the PPS do not refer to the VPS, and do not refer to sets of layer sequence parameters, LPS of the plurality of video data layers and, preferably, in which the encoding of the plurality of video data layers based at least in part on the VPS comprises encoding the plurality of video data layers based at least partly on the VPS , the PPS and the LPS, such that when a syntactic element of one of the PPS conflicts with the VPS or a respective one of the lPs, encode a corresponding one of the plurality of layers of video data based on the syntactic element from one of the PPS. The method according to claim 1, further comprising the coding of a set of grouping parameters, GPS, which groups all the sets of parameters, including the VPS, for the plurality of layers of video data together and preferably, in which Encoding the GPS comprises the information coding that defines a GPS identifier, the method also comprising the information coding of a fragment header corresponding to the GPS identifier. The method according to claim 1, wherein the coding of the plurality of layers of video data comprises decoding the plurality of layers of video data, and wherein the coding of the VPS comprises analyzing the VPS. The method according to claim 1, wherein the encoding of the plurality of layers of video data comprises encoding the plurality of layers of video data, and wherein encoding the VPS comprises constructing the VPS. A device for encoding video data, the device comprising: 5 10 fifteen twenty 25 30 means for encoding (20, 30) a set of video parameters, VPS, for a plurality of layers of video data, in which each of the plurality of layers of video data refers to the VPS and in which the means for encoding the VPS comprise: means for encoding VPS data indicative of a certain number of frames to be rearranged in at least one among the plurality of layers of video data, means for encoding VPS data indicative of a certain number of images to be stored in a buffer of decoded images, DPB, during decoding of the plurality of video data layers, and means for encoding VPS data indicative of a maximum number of time layers in the plurality of video data layers; Y means for encoding (20, 30) the plurality of layers of video data based at least in part on the VPS. The device according to claim 13, wherein the means for encoding the VPS further comprises at least one of: means for encoding VPS data indicative of one or more sets of hypothetical reference decoder parameters, HRD; or means for encoding VPS data indicative of whether the VPS includes an extension beyond a corresponding standard, and when the VPS includes the extension, data for the extension and in which the means for encoding the plurality of layers of video data comprise means for encoding the plurality of layers of video data in accordance with one of High Efficiency Video Coding, HEVC, Multivist Video Coding, MVC and Scalable Video Coding, SVC. A computer readable storage medium that has instructions stored therein which, when executed, causes a processor to perform the method according to any of claims 1-12.