JP7533609B2 - Encoding and Decoding Video Data - Google Patents

Description

This disclosure relates to encoding and decoding video data.

The "Background Art" discussion provided herein is intended to generally present the context of the present disclosure. The inventors' work, to the extent described in this Background Art section, as well as aspects of the discussion that may not otherwise qualify as prior art at the time of filing, are not admitted expressly or impliedly as prior art to the present invention.

There are several video/image data encoding and decoding systems that involve transforming the video data into a frequency domain representation, quantizing the frequency domain coefficients, and then applying some form of entropy coding to the quantized coefficients. This allows the video data to be compressed. Corresponding decoding or decompression techniques are then applied to recover a reconstruction of the original video data.

"Versatile Video Coding (Draft 8)", JVET-G2001-vE, B. Brass, J. Chen, S. Liu and Y-K. Wang

This disclosure addresses or mitigates issues that arise from this process.

Each aspect and feature of the present disclosure is defined in the accompanying claims.

It should be understood that both the general description above and the detailed description below are illustrative of the present technology, but are not limiting of the present technology.

A more complete understanding of the present disclosure and many of its attendant advantages will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings.

FIG. 1 shows a schematic diagram of an audio/video (A/V) data transmission and reception system using video data compression and decompression. FIG. 2 shows a schematic diagram of a video display system using video data decompression. FIG. 3 illustrates generally an audio/video storage system that employs video data compression and decompression. FIG. 4 shows a schematic diagram of a video camera using video data compression. FIG. 5 shows a schematic diagram of a storage medium. FIG. 6 shows a schematic diagram of a storage medium. FIG. 7 is a schematic diagram showing an overview of a video data compression and decompression device. FIG. 8 shows a schematic of a predictor. FIG. 9 shows a schematic diagram of a set of coding levels. FIG. 10 shows a schematic diagram of a set of coding levels. FIG. 11 illustrates the use of parameter sets in a schematic manner. FIG. 12 shows a schematic diagram of an embodiment of a decoding device. FIG. 13 is a schematic flow chart illustrating the method. FIG. 14 shows a schematic diagram of an embodiment of an encoding device. FIG. 15 is a schematic flow chart illustrating the method.

Turning now to the drawings, Figures 1-4 are provided to provide a schematic diagram of an apparatus or system that utilizes the compression and/or decompression apparatus described below in connection with embodiments of the present technology.

All of the data compression and/or decompression devices described below may be implemented in hardware, in software running on a general purpose data processing device such as a general purpose computer, as programmable hardware such as an application specific integrated circuit (ASIC) or field programmable gate array (FPGA), or as a combination thereof. It will be understood that where an embodiment is implemented by software and/or firmware, such software and/or firmware, as well as non-transitory data storage media on which such software and/or firmware is stored or otherwise provided, are considered embodiments of the present technology.

Figure 1 shows a schematic of an audio/video data transmission and reception system using video data compression and decompression. In this example, the data values being encoded or decoded represent image data.

An input audio/video signal 10 is provided to a video data compressor 20 which compresses at least the video component of the audio/video signal 10 for transmission along a transmission path 30, such as a cable, optical fiber, or wireless link. The compressed signal is processed by a decompressor 40 to provide an output audio/video signal 50. For the return path, a compressor 60 compresses the audio/video signal for transmission along the transmission path 30 to a decompressor 70.

Thus, compressor 20 and decompressor 70 may form one node of the transmission link. Decompressor 40 and compressor 60 may form the other node of the transmission link. Of course, if the transmission link is unidirectional, only one of these nodes will need a compressor and the other will need a decompressor.

2 shows a schematic diagram of a video display system using video data decompression. In particular, a compressed audio/video signal 100 is processed by a decompressor 110 to provide a decompressed signal that can be displayed on a display 120. The decompressor 110 can be implemented as an integral part of the display 120, for example provided in the same housing as the display device. Alternatively, the decompressor 110 can be provided (for example) as a so-called set-top box (STB). It is noted that the term "set-top" does not imply a requirement that the box be placed in any particular orientation or position relative to the display 120, but is simply a term used in the art to denote a device that can be connected to a display as a peripheral device.

Figure 3 shows a schematic of an audio/video storage system using video data compression and decompression. An input audio/video signal 130 is provided to a compressor 140, which generates a compressed signal for storage by a storage device 150, such as a magnetic disk drive, an optical disk drive, a magnetic tape drive, a solid-state storage device such as a semiconductor memory, or other storage device. For playback, the compressed data is read from the storage device 150 and passed to a decompressor 160 for decompression, providing an output audio/video signal 170.

It will be understood that compressed or encoded signals, and storage media such as computer-readable non-transitory storage media that store the signals, are considered embodiments of the technology.

Figure 4 shows a schematic of a video camera using video data compression. In Figure 4, an imaging device 180, such as a charge-coupled device (CCD) image sensor and associated control and readout electronics, generates a video signal that is passed to a compression device 190. A microphone (or microphones) 200 generates an audio signal that is passed to the compression device 190. The compression device 190 generates a compressed audio/video signal 210 (shown generally as schematic stage 220) that is stored and/or transmitted.

The techniques described below relate primarily to video data compression and decompression. It will be appreciated that many existing techniques for audio data compression may be used in conjunction with the described video data compression techniques to generate compressed audio/video signals. Accordingly, a separate description of audio data compression will not be provided. It will also be appreciated that data rates associated with video data, particularly broadcast-quality video data, are generally much higher than data rates associated with audio data (whether compressed or uncompressed). It will therefore be appreciated that uncompressed audio data may accompany compressed video data to form a compressed audio/video signal. Although the present embodiment (illustrated in FIGS. 1-4) relates to audio/video data, it will further be appreciated that the techniques described below have application in systems that simply process (i.e., compress, decompress, store, display, and/or transmit) video data. That is, the embodiments may be applied to video data compression without any associated audio data processing.

Figure 4 thus provides an example of a video capture device with an image sensor and encoding device of the type described below. Figure 2 thus provides an example of a decoding device of the type described below and a display on which the decoded image is output.

By combining Figures 2 and 4, it is possible to provide a video capture device that includes an image sensor 180, an encoding device 190, a decoding device 110, and a display 120 on which the decoded image is output.

5 and 6 show schematic diagrams of storage media for storing compressed data generated by (for example) device 20, 60 or input to device 110, storage media, or stages 150, 220. FIG. 5 shows schematic diagrams of disk storage media such as magnetic or optical disks, and FIG. 6 shows schematic diagrams of solid-state storage media such as flash memory. Note that FIGS. 5 and 6 may also provide examples of computer-readable non-transitory storage media for storing computer software that, when executed by a computer, causes the computer to perform one or more of the methods described below.

The above configurations thus provide examples of video storage devices, capture devices, transmitting devices, or receiving devices embodying any of the present technology.

Figure 7 is a schematic diagram showing an overview of a video/image data compression (encoding) and decompression (decoding) device for encoding and/or decoding video/image data representing one or more images.

The controller 343 controls the operation of the entire apparatus, and in particular the trial encoding process by acting as a selector to select various modes of operation, such as block sizes and shapes, when referring to compression modes, and whether the video data should be losslessly encoded or otherwise encoded. The controller is considered to form part of the image encoder or image decoder (as the case may be). Successive images of the input video signal 300 are fed to the adder 310 and the image predictor 320, which is described in more detail below with reference to FIG. 8. The addition of the intra-image predictor of FIG. 8 to the image encoder/decoder (as the case may be) can take advantage of the features of the apparatus of FIG. 7. However, this does not mean that the image encoder/decoder necessarily requires all the features of FIG. 7.

Adder 310 actually receives the input video signal 300 at its "+" input and the output of image predictor 320 at its "-" input, and performs a subtraction (negative addition) operation to subtract the predicted image from the input image. As a result, a so-called residual image signal 330 is generated, which represents the difference between the actual image and the predicted image.

One reason why a residual image signal is generated is as follows: The data encoding techniques described, i.e., techniques to be applied to the residual image signal, tend to work more efficiently when there is less "energy" in the image to be encoded. Here, the term "efficiently" refers to the generation of a small amount of encoded data, and for a particular image quality level, it is desirable (and considered "efficient") to generate as little data as possible. The reference to "energy" in the residual image relates to the amount of information contained in the residual image. If the predicted image is identical to the actual image, then the difference between the two images (i.e., the residual image) contains zero information (zero energy) and is very easy to encode into a small amount of encoded data. In general, if the prediction process can be performed in a way that works reasonably well so that the content of the predicted image is similar to the content of the image to be encoded, then it is expected that the residual image data will contain less information (less energy) than the input image and therefore be easier to encode into a small amount of encoded data.

Encoding (using adder 310) thus involves predicting an image region of the image to be encoded and generating a residual image region that depends on the difference between the predicted image region and the corresponding region of the image to be encoded. In the context of the techniques described below, the ordered array of data values comprises data values of a representation of the residual image region. Decoding involves predicting an image region of the image to be decoded, generating a residual image region that indicates the difference between the predicted image region and the corresponding region of the image to be decoded, the ordered array of data values comprising data values of a representation of the residual image region, and combining the predicted image region and the residual image region.

We now describe the remaining part of the device, which acts as an encoder (for encoding the residual or difference image).

The residual image data 330 is provided to a transform unit/circuit 340 which generates a discrete cosine transform (DCT) representation of the block or region of residual image data. DCT techniques are well known per se and will not be described in detail here. It should also be noted that the use of the DCT is merely illustrative of one exemplary configuration. Examples of other transforms that may be used include, for example, a discrete sine transform (DST). The transforms may also include sequences or cascades of individual transforms, such as one transform followed (either directly or not) by another. The choice of transform may be explicitly determined and/or may depend on side information used to configure the encoder and decoder. In another example, a so-called "transform skip" mode may be selectively used, in which no transform is applied.

Thus, in various embodiments, the encoding and/or decoding method comprises predicting an image region of an image to be encoded and generating a residual image region that depends on the difference between the predicted image region and a corresponding region of the image to be encoded, and the ordered array of data values (described below) comprises data values of a representation of the residual image region.

The output of transform unit 340, i.e. (in one example) a set of DCT coefficients for each transformed block of image data, is provided to quantizer 350. A variety of quantization techniques are known in the field of video data compression, ranging from simple multiplication by a quantization scaling factor to the application of complex look-up tables under the control of a quantization parameter. The general purpose is twofold. First, the quantization process reduces the number of possible values of the transformed data. Second, the quantization process can increase the likelihood that the value of the transformed data is zero. Both of these allow the entropy coding process described below to work more efficiently in generating small amounts of compressed video data.

The data scanning process is applied by the scanner 360. The objective of the scanning process is to reorder the quantized transformed data to collect as many non-zero quantized transform coefficients as possible, and therefore, of course, as many zero-valued coefficients as possible. These features may allow so-called run-length coding or similar techniques to be applied efficiently. The scanning process thus involves selecting coefficients from the quantized transformed data, and in particular from blocks of coefficients corresponding to blocks of transformed and quantized image data, according to a "scan order" such that (a) all coefficients are selected once as part of the scan, and (b) the scan is likely to provide the desired reordering. One example of a scan order that is likely to give useful results is the so-called orthogonal diagonal scan order.

The scanning order may differ between transform skip blocks and transform blocks (blocks that have undergone at least one spatial frequency transformation).

The scanned coefficients are then passed to an entropy encoder (EE) 370. Again, various types of entropy coding may be used. Two examples include variations of the so-called Context Adaptive Binary Arithmetic Coding (CABAC) system, and variations of the so-called Context Adaptive Variable-Length Coding (CAVLC) system. Generally, CABAC is considered to be more efficient, and some studies have shown a 10% to 20% reduction in the amount of coded output data for comparable image quality compared to CAVLC. However, CAVLC is considered to have a much lower level of complexity (in terms of its implementation) than CABAC. Note that although the scanning and entropy encoding processes are shown as separate processes, in practice they may be combined or treated as one. That is, the data may be read into the entropy encoder in scan order. The same applies to the respective inverse processes described below.

The output of the entropy encoder 370 provides a compressed output video signal 380, together with additional data (described above and/or below) that defines, for example, how the predictor 320 generated the predicted image, whether the compressed data was transformed or transformed skipped, etc.

However, because the operation of the predictor 320 itself depends on the decompressed output data, a return path 390 is also provided.

The reason for this feature is as follows: At an appropriate stage of the decompression process (described below), a decompressed residual data is generated. This decompressed residual data must be added to the predicted image to generate the output image (since the original residual data is the difference between the input image and the predicted image). For this process to be similar on the compression side and on the decompression side, the predicted image generated by the predictor 320 should be the same during the compression process as it is during the decompression process. Of course, during decompression, the device does not have access to the original input image, only the decompressed image. Thus, during compression, the predictor 320 bases its predictions (at least for inter-image coding) on the decompressed version of the compressed image.

The entropy coding process performed by the entropy encoder 370 is considered (at least in some examples) to be "reversible", i.e. it can be performed in reverse to arrive at the exact same data that was originally fed to the entropy encoder 370. Thus, in such examples, a return path may be implemented before the entropy coding stage. Indeed, the scanning process performed by the scanner 360 is also considered to be reversible, so that in this embodiment the return path 390 is from the output of the quantizer 350 to the input of the complementary inverse quantizer 420. If losses or potential losses are introduced by a stage, that stage (and vice versa) may be included in the feedback loop formed by the return path. For example, the entropy coding stage may be made at least in principle non-reversible, for example by a technique in which bits are coded within the parity information. In such cases, the entropy coding and decoding should form part of the feedback loop.

In general, the entropy decoder 410, inverse scan unit 400, inverse quantizer 420, and inverse transform unit/circuit 430 provide the inverse functions of the entropy encoder 370, scan unit 360, quantizer 350, and transform unit 340, respectively. We now proceed through the compression process; the process for decompressing the input compressed video signal is described separately below.

In the compression process, the scanned coefficients are passed by return path 390 from quantizer 350 to inverse quantizer 420, which performs the inverse operation of scanner 360. Inverse quantization and inverse transform processes are performed by inverse quantizer 420 and inverse transform unit/circuit 430 to produce a decompressed residual image signal 440.

The image signal 440 is added to the output of the predictor 320 in adder 450 to produce a reconstructed output image 460 (which may, however, be subjected to so-called loop filtering and/or other filtering before being output, see below). This forms one input to the image predictor 320, as described below.

Now consider the decoding process applied to decompress the received compressed video signal 470. The signal is fed to the entropy decoder 410, from there to the inverse scan unit 400, the inverse quantizer 420 and the inverse transform unit 430, before being added to the output of the image predictor 320 by the adder 450. Thus, on the decoder side, the decoder reconstructs a residual image version of the image and then applies this (block by block) to the predicted version of the image (by the adder 450) to decode each block. In short, the output 460 of the adder 450 forms the output decompressed video signal 480 (subject to a filtering process described below). In practice, further filtering may optionally be applied (for example by a loop filter 565, shown in FIG. 8 but omitted from FIG. 7 for better clarity) before the signal is output.

The apparatus of Figures 7 and 8 can act as a compression (encoding) apparatus or a decompression (decoding) apparatus. The functions of these two types of apparatus are substantially overlapping. Scanner 360 and entropy encoder 370 are not used in decompression mode (described in more detail below), and the operation of predictor 320 and other units is subject to mode and parameter information contained in the received compressed bitstream, and do not generate such information themselves.

Figure 8 shows a schematic diagram of the generation of a predicted image, and in particular the operation of the image predictor 320.

There are two basic modes of prediction performed by the image predictor 320: the so-called intra-picture prediction and the so-called inter-picture or motion compensated (MC) prediction. On the encoder side, each involves finding a prediction direction with respect to the current block to be predicted and generating a predictive block of samples according to other samples (in the same picture (intra-picture) or in other pictures (inter-picture)). By adder 310 or 450, the difference between the predictive block and the actual block is coded or applied to code or decode the block, respectively.

(In a decoder, or in the inverse decoding side of an encoder, detection of the prediction direction may be responsive to data associated with the data encoded by the encoder that indicates which direction was used in the encoder, or the detection may be responsive to the same factors as the decision was made in the encoder.)

Intra-picture prediction predicts the content of a block or region of an image based on data from within the same image. This corresponds to the so-called I-frame coding in other video compression techniques. However, in contrast to I-frame coding, which codes the entire image by intra-coding, in this embodiment the choice between intra-coding and inter-coding can be made on a block-by-block basis, whereas in other embodiments the choice is still made on a picture-by-picture basis.

Motion compensated prediction is an example of inter-picture prediction, which exploits motion information that attempts to define sources in other adjacent or nearby pictures of image details to be coded in the current picture. Thus, in an ideal case, the contents of a block of image data in a predicted picture can be coded very simply as a reference (motion vector) that points to a corresponding block at the same or slightly different position in an adjacent picture.

The technique known as "block copy" prediction is in some ways a hybrid of the two predictions, since it uses a vector to indicate a block of samples that is displaced from the currently predicted block in the same image, and is then copied to form the currently predicted block.

Returning to FIG. 8, two image prediction configurations (corresponding to intra-picture prediction and inter-picture prediction) are shown, the results of which predictions are selected by a multiplexer 500 under the control of a mode signal 510 (e.g. from the controller 343) to provide a block of predicted images for feeding to the adders 310 and 450. The selection is made according to which selection gives the lowest "energy" (which, as described above, can be considered as the information content that needs to be coded) and is signaled to the decoder in the coded output data stream. In this context, the image energy can be found, for example, by trial subtracting an area of the two versions of the predicted image from the input image, squaring each pixel value of the difference image, summing the squared values, and identifying which of the two versions gives rise to a lower mean squared value of the difference image associated with that image region. In another example, a trial encoding can be performed for each selection or possible selections, and then a selection is made according to the cost of each possible selection in terms of the number of bits required for coding and/or image distortion.

In an intra-coding system, the actual prediction is made on the basis of the image blocks received as part of the signal 460 (the signal as filtered by loop filtering, see below), i.e. the prediction is made on the basis of the coded and decoded image blocks so that the exact same prediction can be performed in the decompressor. However, the intra-mode selector 520 can derive data from the input video signal 300 to control the operation of the intra-picture predictor 530.

For inter-picture prediction, the motion compensation (MC) predictor 540 uses motion information, such as motion vectors derived by the motion estimator 550 from the input video signal 300. These motion vectors are applied by the motion compensation predictor 540 to the processed reconstructed image 460 to generate blocks of inter-picture prediction.

Thus, each of the predictors 530 and 540 (operating with the estimator 550) acts as a detector for detecting a prediction direction with respect to the current block to be predicted, and as a generator for generating a predictive block of samples (forming part of the prediction passed to the adders 310 and 450) according to other samples defined by the prediction direction.

Next, we will explain the processing applied to signal 460.

First, the signal may be filtered by a so-called loop filter 565. Various types of loop filters can be used. One technique involves applying a "deblocking" filter to remove or at least tend to reduce the effects of the block-based processing and subsequent operations performed by the transform unit 340. Further techniques may be used including applying a so-called sample adaptive offset (SAO) filter. In general, in a sample adaptive offset filter, the filter parameter data (derived in the encoder and communicated to the decoder) defines one or more offset amounts that are selectively combined by the sample adaptive offset filter with a given intermediate picture sample (a sample of the signal 460) depending on (i) the value of the given intermediate picture sample, or (ii) the value of one or more intermediate picture samples having a predetermined spatial relationship to the given intermediate picture sample.

An adaptive loop filter is also optionally applied, using coefficients derived by processing the reconstructed signal 460 and the input video signal 300. An adaptive loop filter is a type of filter that applies adaptive filter coefficients to the data to be filtered, using known techniques. That is, the filter coefficients may vary depending on a variety of factors. Data defining which filter coefficients to use is included as part of the encoded output data stream.

The techniques described below relate to handling of parameter data related to the operation of the filter. The actual filtering operation (such as SAO filtering) may otherwise use known techniques.

The filtered output from the loop filter 565 actually forms the output video signal 480 when the device is operating as a decompressor. The output is also buffered in one or more image or frame stores 570, the storage of successive images being a requirement of the motion compensation prediction process, particularly the generation of motion vectors. To facilitate the storage requirements, the stored images in the image store 570 may be kept in a compressed state and then decompressed for use in generating the motion vectors. Any known compression/decompression system may be used for this particular purpose. The stored images may be passed to an interpolation filter 580 which generates a higher resolution image from the stored images. In this example, intermediate samples (sub-samples) are generated such that the resolution of the interpolated image output by the interpolation filter 580 is four times (in each dimension) the image stored in the image store 570 for the luminance channel at 4:2:0 and eight times (in each dimension) the image stored in the image store 570 for the chrominance channel at 4:2:0. The interpolated image is passed as an input to the motion estimator 550 and also to the motion compensated predictor 540.

We now describe how to partition an image for compression processing. At a basic level, an image to be compressed is considered as an array of blocks or regions of samples. Partitioning an image into such blocks or regions can be performed by decision trees such as those described in "SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services - Coding of moving video High efficiency video coding Recommendation ITU-T H.265 12/2016" and "High Efficiency Video Coding (HEVC) Algorithms and Architectures, Chapter 3, Editors: Madhukar Budagavi, Gary J. Sullivan, Vivienne Sze; ISBN 978-3-319-06894-7; 2014," each of which is incorporated herein by reference in its entirety. Further background information is provided in "Analyzing the Image of a Multimedia Scene," vol. 14, No. 1, pp. 1111-1119, 2013. This non-patent document 1 is also incorporated herein in its entirety by reference.

In some examples, the resulting blocks or regions have a size and possibly a shape that can generally follow the arrangement of image features in the image by the decision tree. This in itself can improve coding efficiency, since such configurations tend to group together samples that represent or follow similar image features. In some examples, square blocks or regions of different sizes (e.g., 4×4 samples, up to, e.g., 64×64 or larger blocks) are available for selection. In other exemplary configurations, blocks or regions of different shapes can be used, such as rectangular blocks (e.g., vertically or horizontally oriented). Other non-square and non-rectangular blocks are also envisioned. As a result of dividing the image into such blocks or regions, each sample of the image (at least in this example) is assigned to only one such block or region.

The embodiments of the present disclosure described below relate to techniques for representing coding levels in an encoder and a decoder.

(Parameter Sets and Coding Levels)
When encoding video data by the techniques described above for subsequent decoding, it is appropriate for the encoding side of the process to communicate some parameters of the encoding process to the final decoding side of the process. Considering that these encoding parameters are needed whenever decoding the encoded video data, it is useful to associate the parameters with the encoded video data stream itself, for example by embedding them as so-called parameter sets in the encoded video data stream itself (as they can be transmitted "out of band" by a separate transmission channel, although not necessarily exclusively).

Parameter sets may be represented as a hierarchy of information, e.g., as a video parameter set (VPS), a sequence parameter set (SPS), and a picture parameter set (PPS). The PPS occurs once for each picture and contains information relevant to all coded slices in that picture, the SPS occurs less frequently (once per sequence of pictures), and the VPS is expected to occur even less frequently. More frequently occurring parameter sets (such as the PPS) may be implemented as references to previously coded instances of that parameter set to avoid the cost of re-encoding. Each coded image slice references a single active PPS, SPS, and VPS to provide information used in decoding that slice. In particular, each slice header may contain a PPS identifier to reference the PPS, which in turn references the SPS, which in turn references the VPS.

Among these parameter sets, the SPS contains exemplary information relevant to some of the following descriptions, namely data defining the so-called profiles, hierarchies, and coding levels to be used.

A profile defines the set of decoding tools or features to be used. Examples of profiles include "Main Profile", which relates to 8-bit 4:2:0 video, and "Main 10 Profile", which allows 10-bit resolution and other extensions over Main Profile.

The coding level imposes restrictions on things like maximum sampling rate and picture size. The hierarchy specifies the maximum data rate.

In the Joint Video Experts Team (JVET) proposal for versatile video coding (VVC), as defined (as of the filing date) in the referenced JVET-Q2001-vE standard, various levels are defined, from 1 to 6.2.

The highest possible level is level 8.5, this limit is derived from the encoding used, levels are encoded in 8 bits as level*30, which means that level 8.5 is encoded as a maximum 8-bit value of 255.

The current standard also defines a condition that a decoder conforming to a given profile at a particular level in a particular hierarchy is capable of decoding all bitstreams for which the following condition applies, i.e., the bitstream indicates conformance to a level (of a given profile at a given hierarchy) that is not level 8.5 but is equal to or lower than the specified level.

Figure 9 shows a schematic of the currently defined levels with example picture sizes and frame rates that represent the amalgamation of the respective conditions imposed by the two example tables (A.1 and A.2) of the JVET document. The major components of the levels (indicating the maximum luminance picture size and increasing monotonically as the maximum luminance picture size increases) are indicated by integers in the left column, while the minor components of the levels (indicating at least one of the maximum luminance sampling rate and the maximum frame rate and, for a given first component, the second component increases monotonically as the maximum luminance sampling rate increases and increases monotonically as the maximum frame rate increases) are indicated by the numbers after the decimal point.

Note that in principle one of the maximum luma sampling rate and maximum frame rate can be derived from the other and from the maximum luma picture size, so although for clarity of exposition both are specified in the table, only one of the two needs to be specified.

Data rates, picture sizes, etc. are defined for the luminance (or luma) component, and the corresponding data for chrominance (chroma) can be derived from the chrominance subsampling format in use (e.g. 4:2:0 or 4:4:4), which defines for a given number of luminance samples a corresponding number of chrominance samples.

Note that the column labeled "Example Maximum Luma Size" simply provides examples of luma picture configurations that comply with the number of samples defined by the respective maximum luma picture sizes and also comply with the aspect ratio constraints imposed by other parts of the standard (this column is for illustrative purposes only and does not form part of the standard).

(Possible issues to be addressed)
There are several potential problems with the current level of specification that may be addressed, at least in part, by the exemplary embodiments described below.

First, as defined, it is not worthwhile to create a new level between different existing levels. For example, levels 5.2 and 6 have the same value of MaxLumaSr. The only thing that can be changed is to have some intermediate picture sizes, but this is not considered to be particularly useful.

Second, for a given level picture size, you cannot exceed 120 fps (frames per second). The only choice is to use a level with a larger picture size. This is because a change to a frame rate above 120 fps would exceed the maximum luma sampling rate applicable to the next level. For example, a new level (say 5.3) cannot be defined at 240 fps for 4K, because this would require a sampling rate twice that of the current level 6 sampling rate, which is the current requirement for a level 6 decoder to decode a level 5.X stream.

Third, the maximum level is 8.5, which implies a maximum image size of at least 32K (e.g., 32768x17408) that is not defined in the current standard (due to the existing exponent relationship for levels 4 and above). While this may not seem like an immediate problem, it could cause problems for future omnidirectional applications that use, for example, subpictures.

To address these issues, we propose a method and apparatus for encoding (and decoding) levels. In addition, we also propose alternative constraints on the ability to decode the stream.

Level Encoding in an Exemplary Embodiment
An alternative level coding that we propose is as follows:

Level is coded in 8 bits as major*16 + minor.

Here, "major" refers to the integer value and "minor" refers to the decimal value. So, for level 5.2 (for example), major = 5 and minor = 2.

So for example, level 4.1 would be coded as 65, and the maximum level is 15.15.

This organization means that the set of levels does not "waste" code for levels that cannot be defined for the reasons mentioned above, or at least does not waste that code within the scope of the current system.

Also, increase the maximum possible value from 8.5 to 15.15.

Note that an alternative encoding could make the level code easily visible in a hex dump representation: the first hex digit represents the major component and the second hex digit represents the minor component.

However, below are some alternative examples, any of which (or indeed any other examples) may be considered to be within the scope of the appended claims.

(Level Decryption Constraints)
To address the issue of higher frame rates that are not currently possible without using higher levels (and thus forcing the use of longer line buffers, etc.), in accordance with an exemplary embodiment, the constraints on the ability to decode the stream are modified.

The modified constraint defines that a decoder conforming to a given profile at a particular level D.d (D denotes the main component and d denotes the secondary component) of a given hierarchy can decode all bitstreams (of a given profile at a given hierarchy) for which the following conditions apply: a bitstream is shown to conform to a level S.s (main component. secondary component) that is not level 15.15, s is less than or equal to d, and S*2+s is less than or equal to D*2+d.

With these configurations, new minor levels for higher frame rates may be added without requiring a decoder for the next major level that can decode the higher sampling rate.

This constraint is fully backwards compatible with all currently defined levels and has no effect on decoders. However, it allows the creation of higher frame rate decoders at lower layers than is currently possible.

(Example - Figure 10)
FIG. 10 provides an example in which a new level 5.3 is inserted into the list of FIG. 9, having the same maximum luma picture size as the other levels with measure=5, but a maximum luma sampling rate and maximum frame rate that are twice as high as the previous level 5.2.

Applying the above expression, the new level 5.3 occupies otherwise unused coding (16*5)+3=83.

[0110] Applying the above decoding constraints, a level 5.3 video data stream is decodable by a level 6.1 decoder because:
5 is less than or equal to 6, and
Because 5*2+3 is less than or equal to 6*2+1.

Thus, in an exemplary embodiment, an alternative method for encoding levels is provided that increases the maximum level from 8.5 to 15.15, and an alternative constraint is also proposed that allows adding levels with higher frame rates to decode the increased bitrate without requiring a decoder for all the higher levels.

(Example)
Next, an embodiment will be described with reference to the drawings.

Figure 11 illustrates the use of the video parameter sets and sequence parameter sets mentioned above in a schematic way. In particular, they form part of a hierarchy of parameter sets mentioned above, such that a number of sequence parameter sets 1100, 1110, and 1120 may reference a video parameter set 1130, which in turn may themselves be referenced by respective sequences 1102, 1112, and 1122. In an exemplary embodiment, level information applicable to each sequence is provided within the sequence parameter set.

However, it will be appreciated that in other embodiments, the level information may be provided in a different format or with a different set of parameters.

Similarly, although the schematic diagram of FIG. 11 shows sequence parameter sets provided as part of the overall video data stream 1140, the sequence parameter sets (or other data structure conveying level information) may instead be provided by a separate communication channel. In either case, the level information is associated with the video data stream 1140.

(Operation example - decoder)
Figure 12 illustrates generally an aspect of a decoding device configured to receive an input (encoded) video data stream 1200 and generate and output a decoded video data stream 1210 using a decoder 1220 as described above with reference to Figure 7. For clarity of illustration, the control circuitry/controller 343 of Figure 7 has been depicted separately to the remainder of the decoder 1220.

Among the functions of the controller/control circuitry 343 is a parameter set (PS) detector 1230 that detects various parameter sets, including VPS, SPS, and PPS, from appropriate fields in the input video data stream 1200. The parameter set detector 1230 derives information from the parameter sets, including the levels as described above. This information is passed to the remainder of the control circuitry 343. Note that the parameter set detector 1230 can decode the levels or simply provide the encoded levels to the control circuitry 343 for decoding.

The control circuitry 343 is also responsive to one or more decoder parameters 1240 that define, for example, at least the level to which the decoder 1220 can decode using the above numbering scheme (major.minor).

The control circuitry 343 detects, for a given or current input video data stream 1200, whether the decoder 1220 is capable of decoding that input video data stream and controls the decoder 1220 accordingly. The control circuitry 343 may also provide various other operating parameters to the decoder 1220 in response to information obtained from the parameter set detected by the parameter set detector 1230.

Figure 13 is a schematic flowchart showing these operations on the decoder side.

In step 1300, the parameter set decoder 1230 detects the SPS and provides this information to the control circuit 343. The control circuit 343 also detects the decoder parameters 1240.

From the encoded levels, the control circuit 343 detects (at step 1310) a level coefficient N, where N is a first predetermined constant (16 in this example). The control circuit 343 detects (at step 1320) a level remainder M divided by N, where M is a second predetermined constant (1 in this example, but could be, for example, 2 or 4, or 3 in another example). The result of step 1310 provides the principal component, and the result of step 1320 provides the secondary component.

Then, in step 1330, the control circuit 343 detects whether the current input video data stream 1200 can be decoded by applying the following tests to the decoder parameter value D.d and the input video stream parameter value S.s, as described above:

Is the encoding level = 255 (S.s stands for 15.15)?
If so, then 15.15 is a special case indicating a non-standard level and is therefore not decodable. If not, move to the next test.
-Is S less than or equal to D and is S*2+S less than or equal to D*2+D?
If so, it is decodable, otherwise it is not decodable.

The first part of this test is optional and can be omitted.

If the answer is no, processing proceeds to step 1340, where the control circuit 343 instructs the decoder 1220 not to decode the input video data stream.

However, if the answer is affirmative, processing proceeds to steps 1350 and 1360, where the maximum luma picture size (step 1350) and the maximum luma sampling rate and/or maximum frame rate (step 1360) are found using a mapping provided by a stored table such as that shown in FIG. 10. Based on these derived parameters, the control circuit 343 controls the decoder 1220 to decode the input video data stream 1200 in step 1370.

There is thus provided a method of operating a video data decoder, comprising the steps of:
Detecting (1300) a parameter value associated with an input video data stream, the parameter value indicating an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate;
the encoding level defines a first numerical component and a second numerical component, the second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
the parameter value being a numerical encoding of the encoding level as the sum of a first predetermined constant multiplied by the first numerical component and a second predetermined constant multiplied by the second numerical component;
performing (1330) predetermined tests on parameter values associated with a given input video data stream with respect to performance data for the video data decoder;
controlling (1370) the video data decoder to decode the given input video data stream when parameter values associated with the given input video data stream succeed the predetermined test on performance data for the video data decoder;
controlling (1340) the video data decoder not to decode the given input video data stream when parameter values associated with the given input video data stream fail the predefined test related to performance data for the video data decoder.
An example method of operation is provided.

The arrangement of FIG. 12 operates according to the method of FIG. 13;
a video data decoder 1220 for decoding an input video data stream, said video data decoder 1220 being responsive to parameter values associated with said input video data stream, said parameter values indicating an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate;
The encoding level defines a first numerical component and a second numerical component, the second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
the parameter value being a numerical encoding of the encoding level as the sum of a first predetermined constant multiplied by the first numerical component and a second predetermined constant multiplied by the second numerical component;
a comparator 343 configured to perform predetermined tests on parameter values associated with a given input video data stream with respect to performance data for said video data decoder;
and a control circuit 343 configured to control the video data decoder to decode the given input video data stream when parameter values associated with the given input video data stream pass the predefined test on performance data for the video data decoder, and to control the video data decoder not to decode the given input video data stream when parameter values associated with the given input video data stream fail the predefined test on performance data for the video data decoder.

(Working example - Encoder)
Similarly, Figure 14 illustrates diagrammatically an aspect of an encoding apparatus comprising an encoder 1400, for example of the type described above with reference to Figure 7. The encoder's control circuitry 343 is depicted separately for clarity of illustration. The encoder operates on an input video data stream 1410 to produce an output encoded video data stream 1420 under the control of the control circuitry 343, which is responsive to encoding parameters 1430 including a definition of the encoding level to be applied.

The control circuitry 343 also includes or controls a parameter set generator 1440 that generates a parameter set including, for example, a VPS, an SPS, and a PPS to be included in the output encoded video data stream, the SPS conveying the encoded level information as described above.

Next, the operation of this device will be explained with reference to the schematic flow chart in Figure 15.

Step 1500 represents, for example, the establishment of an encoding level according to the encoding parameters 1430, the encoding level being represented by (major.minor) or in other words (first component.second component).

In step 1510, the control circuit 343 controls the encoder 1400 according to the established encoding level.

Separately, to encode the encoding level, the parameter set generator 1440 multiplies the first component (major) by a first predefined constant N (16 in this example) in step 1520, multiplies the second component (minor) by a second predefined constant M (1 in this example, but 3 in other examples described below) in step 1530, and then adds the two results in step 1540 to generate the encoding level information. Based on this, the parameter set generator 1440 generates the required parameter set including the encoded level information in step 1550.

Therefore, this results in:
(in response to 1510) encoding the input video data stream to generate an output encoded video data stream according to an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate, said encoding level defining a first numerical component and a second numerical component, said second numerical component being a numerical value greater than or equal to zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
encoding (1520, 1530, 1540, 1550) a parameter value for association with said output video data stream, said parameter value being a numerical encoding of said encoding level as the sum of a first predetermined constant multiplied by said first numerical component and a second predetermined constant multiplied by said second numerical component.

The arrangement of FIG. 14 operates according to the method of FIG. 15;
a video data encoder 1400 configured to encode an input video data stream to generate an output encoded video data stream according to an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate, said encoding level defining a first numerical component and a second numerical component, said second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
and a parameter value encoding circuit 1440 for encoding a parameter value for association with said output video data stream, said parameter value being a numerical encoding of said encoding level as the sum of a first predetermined constant multiplied by said first numerical component and a second predetermined constant multiplied by said second numerical component.

In the encoding or decoding examples above, the second component may increase monotonically with the maximum luma sampling rate. In other examples, the second component may vary with the maximum luma sampling rate for a given first numerical component. In other examples, the second component may increase monotonically with the maximum luma sampling rate for a given first numerical component.

In another example, for an encoding level having at least a threshold value of the first component, the first component increases monotonically with increasing maximum luma picture size and the second component indicates at least one of the maximum luma sampling rates, and for a given first component, the second component varies with the maximum luma sampling rate.

A second numeric component of zero is represented typographically in the accompanying table by the absence of a second digit (after the decimal point).

Regarding the sentence "For coding levels having a second numerical component of zero, the first numerical component increases monotonically with increasing maximum luminance picture size," this indicates that for m>n, the maximum luminance picture size for level m.0 (or "m") is at least as large as for level n.0 (or n).

(More examples)
A further alternative encoding of the proposed levels is as follows:

Level is encoded in 8 bits as major*16 + minor*3.

Here, as above, "major" refers to the integer value and "minor" refers to the decimal value. So, for level 5.2 (for example), major = 5 and minor = 2.

So, for example, level 4.1 would be coded as 67, and the maximum level that can be coded with this technique is 15.5.

As mentioned above, this arrangement means that the set of levels does not "waste" code for levels that cannot be defined for the reasons mentioned above, or at least does not waste that code within the scope of the current system.

This also increases the maximum possible value from 8.5 to 15.5.

Examples of coding levels using this configuration are as follows:

(Encoded Video Data)
Video data encoded according to any of the techniques disclosed herein is also considered to represent an embodiment of the present disclosure.

(Annex - Draft changes to JVET-Q2001-vE standard to reflect implementation examples [A.3.1 Main 10 Profile])
A bitstream conforming to the Main 10 Profile shall adhere to the following constraints:
The reference SPS shall have chroma_format_idc equal to 0 or 1.
The reference SPS shall have a bit_depth_minus8 in the range 0 to 2, inclusive.
The reference SPS shall have sps_palette_enabled_flag equal to 0.
general_level_idc and sublayer_level_idc[i] shall not be equal to 255 (indicating level 15.15) for all values of i in the VPS (if available) and the reference SPS.
Where applicable, the tier and level constraints specified for the Main 10 Profile in Section A.4 shall be met.

Conformance of a bitstream to the main 10 profile is indicated by general_profile_idc equal to 1.

A decoder conforming to the Main 10 profile at a particular level D.d of a particular hierarchy shall be able to decode all bitstreams for which all of the following conditions apply:
The bitstream is shown to conform to the Main 10 profile.
The bitstream is indicated as conforming to the specified hierarchical level or lower.
The bitstream is shown to conform to level S.s, which is less than or equal to D, rather than level 15.15, where S*2+s is less than or equal to D*2+d.

[A.3.2 Main 4:4:4 10 Profile]
A bitstream conforming to the Main 4:4:4 10 profile shall adhere to the following constraints:
The reference SPS shall have a chroma_format_idc in the range 0 to 3, inclusive.
The reference SPS has a bit_depth_minus8 in the range 0 to 2, inclusive.
general_level_idc and sublayer_level_idc[i] shall not be equal to 255 (indicating level 15.15) for all values of i in the VPS (if available) and the reference SPS.
Where applicable, the hierarchical and level constraints specified for the main 4:4:4 10 profile in Section A.4 shall be met.

Conformity of a bitstream to the main 4:4:4 10 profile is indicated by general_profile_idc equal to 2.

A decoder conforming to the Main 4:4:4 10 profile at a particular level D.d of a particular hierarchy shall be able to decode all bitstreams for which all of the following conditions apply:
The bitstream is indicated as conforming to the Main 4:4:4 10 profile or the Main 10 profile.
The bitstream is indicated as conforming to the specified hierarchical level or lower.
The bitstream is shown to conform to level S.s, which is less than or equal to D, rather than level 15.15, where S*2+s is less than or equal to D*2+d.

A.4.1 General Tier and Level Restrictions
Table A.1 specifies the limits for each level of each tier for levels other than Level 15.15.

The tier and level to which the bitstream conforms are indicated by the syntax elements general_tier_flag and general_level_idc, and the level to which the sublayer representation conforms is indicated by the syntax element sublayer_level_idc[i], as follows:

If the specified level is not level 15.15, general_tier_flag equal to 0 indicates conformance to the main tier, general_tier_flag equal to 1 indicates conformance to a higher tier according to the tier constraints specified in Table A.1, and general_tier_flag shall be equal to 0 for levels below level 4 (corresponding to the entries in Table A.1 marked with "-"). Otherwise (if the specified level is 15.15), general_tier_flag equal to 1 is a requirement for bitstream conformance, value 0 for general_tier_flag is reserved for future use by ITU-T|ISO/IEC, and decoders shall ignore the value of general_tier_flag.
general_level_idc and sublayer_level_idc[i] shall be set equal to 16 times the number of major levels specified in Table A.1 plus 1 times the number of minor levels.

All other references to Level 8.5 have also been changed to Level 15.15.

Alternatively, level 15.15 may be specified throughout using a variable name instead, such as "limitless_level_idc", which is defined once as 15.15.

With reference to the above-mentioned alternative embodiments, the following text relates to Appendix 4.1 of JVET-T2001-v1 of the ^20th JVET meeting in October 2020, the contents of which are incorporated herein by reference.

The tier and level to which a bitstream conforms is indicated by the syntax elements general_tier_flag and general_level_idc, and the level to which a sublayer representation conforms is indicated by the syntax element sublayer_level_idc[i], as follows:
If the specified level is not level 15.15, general_tier_flag equal to 0 indicates conformance to the main tier, general_tier_flag equal to 1 indicates conformance to a higher tier according to the tier constraints specified in Table 135, and general_tier_flag shall be equal to 0 for levels below level 4 (corresponding to the entries in Table 135 marked with "-"). Otherwise (if the specified level is 15.15), general_tier_flag equal to 1 is a requirement for bitstream conformance, value 0 for general_tier_flag is reserved for future use by ITU-T|ISO/IEC, and decoders shall ignore the value of general_tier_flag.
general_level_idc and sublayer_level_idc[i] shall be set equal to the general_level_idc for the level number specified in Table 135.

(Note that Table 135 is presented above in relation to an alternative embodiment).

To the extent that embodiments of the present disclosure are described as being implemented, at least in part, by a software-controlled data processing apparatus, it will be understood that a non-transitory computer-readable medium carrying such software, such as an optical disk, a magnetic disk, a semiconductor memory, or the like, is also considered to represent an embodiment of the present disclosure. Similarly, a data signal (whether or not embodied on a non-transitory computer-readable medium) containing encoded data generated according to the method described above is also considered to represent an embodiment of the present disclosure.

It will be apparent that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will therefore be understood that, within the scope of the appended provisions, the present technology may be practiced otherwise than as specifically described herein.

It will be appreciated that in the above description, for purposes of clarity, embodiments have been described with reference to different functional units, circuits and/or processors. However, it will be apparent that any suitable distribution of functionality may be made between different functional units, circuits and/or processors without departing from embodiments of the invention.

The embodiments described herein may be implemented in any suitable form including hardware, software, firmware or any combination of these. The embodiments described herein may optionally be implemented at least in part as computer software running on one or more data processors and/or digital signal processors. The elements and components in any embodiment may be physically, functionally and logically implemented in any suitable way. Indeed, functionality may be implemented in a single unit, in multiple units or as part of other functional units. Thus, embodiments of the present disclosure may be implemented in a single unit or may be physically and functionally distributed between different units, circuits and/or processors.

Although the present disclosure has been described in connection with several embodiments, it is not intended that the disclosure be limited to the specific form set forth herein. Moreover, while features of the present disclosure may be described in connection with particular embodiments, those skilled in the art will recognize that the various features of the described embodiments may be combined in any manner suitable for practicing the present technology.

Each aspect and feature is defined by the following numbered clauses.
1. A video data decoder configured to decode an input video data stream, the video data decoder being responsive to parameter values associated with the input video data stream, the parameter values indicating an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate;
the encoding level defines a first numerical component and a second numerical component, the second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
the parameter value being a numerical encoding of the encoding level as the sum of a first predetermined constant multiplied by the first numerical component and a second predetermined constant multiplied by the second numerical component;
a comparator configured to perform predetermined tests on parameter values associated with a given input video data stream with respect to performance data for said video data decoder;
and a control circuit configured to control the video data decoder to decode the given input video data stream when parameter values associated with the given input video data stream pass the predefined test on performance data for the video data decoder, and to not decode the given input video data stream when parameter values associated with the given input video data stream fail the predefined test on performance data for the video data decoder.
2. The encoding/decoding device according to 1. above,
The predetermined test includes detecting, for the first numerical component (S) and the second numerical component (s) represented by the parameter values associated with the given input video data stream and a first numerical component (D) and a second numerical component (d) of the performance data for the video data decoder, whether (i) s is less than or equal to d, and (ii) S*2+s is less than or equal to D*2+d.
3. The encoding/decoding device according to 1 or 2 above, further comprising:
An encoding/decoding apparatus comprising: a detector configured to detect said parameter values from a parameter set associated with said input video data stream.
4. The encoding/decoding device according to 3 above,
The parameter set is a sequence parameter set.
5. The encoding/decoding device according to any one of 1 to 4 above,
The first predetermined constant is 16.
6. The encoding/decoding device according to any one of 1. to 5.,
The encoding/decoding device, wherein the second predetermined constant is 1.
7. The encoding/decoding device according to any one of 1. to 5.,
The second predetermined constant is 3.
8. The encoding/decoding device according to any one of 1 to 7 above,
The parameter value comprises an 8-bit value.
9. The encoding/decoding device according to any one of 1. to 8.,
The predetermined test comprises detecting whether the parameter value associated with the input video data stream is not equal to 255.
10. A video storage device, capture device, transmission device or reception device comprising the encoding/decoding device according to any one of 1 to 9 above.
11. A video data encoder configured to encode an input video data stream and generate an output encoded video data stream according to an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate;
the encoding level defines a first numerical component and a second numerical component, the second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
1. An encoding/decoding apparatus comprising: a parameter value encoding circuit configured to encode a parameter value for association with said output video data stream, said parameter value being a numerical encoding of said encoding level as the sum of a first predetermined constant multiplied by said first numerical component and a second predetermined constant multiplied by said second numerical component.
12. The encoding/decoding device according to 1. above,
The parameter value encoding circuitry is configured to encode the parameter values as at least part of a parameter set associated with the encoded output video data stream.
13. The encoding/decoding device according to 1. above,
The parameter set is a sequence parameter set.
14. The encoding/decoding device according to any one of 11 to 13 above,
The first predetermined constant is 16.
15. The encoding/decoding device according to any one of 11 to 14 above,
The encoding/decoding device, wherein the second predetermined constant is 1.
16. The encoding/decoding device according to any one of 11 to 14 above,
The second predetermined constant is 3.
17. The encoding/decoding device according to any one of 11 to 16 above,
The parameter value comprises an 8-bit value.
18. A video storage device, capture device, transmission device or reception device comprising the encoding/decoding device according to any one of 11 to 17 above.
19. A method of operating a video data decoder, comprising the steps of:
detecting a parameter value associated with the input video data stream, the parameter value indicating an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate;
the encoding level defines a first numerical component and a second numerical component, the second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
the parameter value being a numerical encoding of the encoding level as the sum of a first predetermined constant multiplied by the first numerical component and a second predetermined constant multiplied by the second numerical component;
performing predetermined tests on parameter values associated with a given input video data stream with respect to performance data for said video data decoder;
controlling said video data decoder to decode said given input video data stream when parameter values associated with said given input video data stream succeed said predetermined test on performance data for said video data decoder;
A method of operating the video data decoder such that the video data decoder does not decode the given input video data stream when parameter values associated with the given input video data stream fail the predefined test relating to performance data for the video data decoder.
20. A computer-readable non-transitory storage medium storing computer software which, when executed by a computer, causes said computer to perform the operating method recited in 19. above.
21. Encoding an input video data stream to generate an output encoded video data stream according to an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate, said encoding level defining a first numerical component and a second numerical component, said second numerical component being a numerical value greater than or equal to zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second component varies with the maximum luminance sampling rate;
encoding a parameter value for association with said output video data stream, said parameter value being a numerical encoding of said coding level as the sum of a first predetermined constant multiplied by said first numerical component and a second predetermined constant multiplied by said second numerical component.
22. A computer-readable non-transitory storage medium storing computer software which, when executed by a computer, causes said computer to perform the operational method recited in 21 above.

Claims (11)

1. An apparatus comprising a video data decoder and a control circuit,
the video data decoder is configured to decode the input video data stream in response to parameter values associated with the input video data stream;
the parameter value indicating an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate;
the encoding level defines a first numerical component and a second numerical component, the second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second numerical component varies with the maximum luminance sampling rate;
the parameter value being a numerical encoding of the encoding level as the sum of a first predetermined constant multiplied by the first numerical component and a second predetermined constant multiplied by the second numerical component;
the control circuitry is configured to perform a predetermined test on parameter values associated with a given input video data stream with respect to performance data for the video data decoder, and is further configured to control the video data decoder to decode the given input video data stream when parameter values associated with the given input video data stream pass the predetermined test with respect to performance data for the video data decoder, and to not decode the given input video data stream when parameter values associated with the given input video data stream fail the predetermined test with respect to performance data for the video data decoder;
The predetermined test includes detecting, for the first numerical component (S) and the second numerical component (s) represented by the parameter values associated with the given input video data stream and a first numerical component (D) and a second numerical component (d) of the performance data for the video data decoder, whether (i) s is less than or equal to d and (ii) S*2+s is less than or equal to D*2+d. 2. The apparatus of claim 1, further comprising:
An apparatus comprising: a detector configured to detect the parameter value from a parameter set associated with the input video data stream. 3. The apparatus of claim 2,
The parameter set is a sequence parameter set. 2. The apparatus of claim 1,
The first predetermined constant is 16. 2. The apparatus of claim 1,
The second predetermined constant is 1. 2. The apparatus of claim 1,
The second predetermined constant is 3. 2. The apparatus of claim 1,
The parameter value comprises an 8-bit value. 2. The apparatus of claim 1,
The predetermined test includes detecting whether the parameter value associated with the input video data stream is not equal to 255. A video storage device, capture device, transmission device, or reception device comprising the device of claim 1. 1. A method of operating a video data decoder, comprising the steps of:
detecting a parameter value associated with the input video data stream, the parameter value indicating an encoding level selected from a plurality of encoding levels, each encoding level defining at least a maximum luma picture size and a maximum luma sampling rate;
the encoding level defines a first numerical component and a second numerical component, the second numerical component being a numerical value equal to or greater than zero;
For coding levels having a second numerical component of zero, said first numerical component increases monotonically with increasing maximum luminance picture size;
the second numerical component varies with the maximum luminance sampling rate;
the parameter value being a numerical encoding of the encoding level as the sum of a first predetermined constant multiplied by the first numerical component and a second predetermined constant multiplied by the second numerical component;
performing predetermined tests on parameter values associated with a given input video data stream with respect to performance data for said video data decoder;
controlling said video data decoder to decode said given input video data stream when parameter values associated with said given input video data stream succeed said predetermined test on performance data for said video data decoder;
controlling said video data decoder not to decode said given input video data stream when parameter values associated with said given input video data stream fail said predetermined test related to performance data for said video data decoder;
The predetermined test includes detecting, for the first and second numerical components (S, s) represented by the parameter values associated with the given input video data stream and a first and second numerical component (D, d) of the performance data for the video data decoder, whether (i) s is less than or equal to d, and (ii) S*2+s is less than or equal to D*2+d. A computer-readable non-transitory storage medium storing computer software that, when executed by a computer, causes the computer to perform the operating method of claim 10.

Images