Adaptive film grain synthesis
Patent Information
- Application Number
- TW111142381
- Authority / Receiving Office
- TW · TW
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2022-10-19
- Filing Date
- 2022-11-07
- Publication Date
- 2026-08-11
- Estimated Expiration
- 2042-11-06
AI Technical Summary
Existing video decoding technologies face challenges in efficiently encoding and decoding film grain noise, which is costly in terms of hardware resources and complexity, particularly due to the need for large line buffers and extensive film grain databases.
The proposed solution involves self-adjusting film grain block sizes based on picture resolution, reducing line buffer usage and film grain database size through methods that determine film grain block height and width dynamically, and optimizing film grain synthesis processes to minimize hardware requirements.
This approach reduces hardware costs and complexity by minimizing the need for large line buffers and film grain databases, while maintaining or improving the quality of film grain synthesis in video decoding.
Smart Images

Figure TWG2TB001905169_001 
Figure TWG2TB001905169_002 
Figure TWG2TB001905169_003
Abstract
Description
Self-adjusting film grain synthesis In summary, this case relates to video processing. For example, the subject of this case concerns improving video decoding technology (e.g., encoding and / or decoding of video) for self-adjusting film grain synthesis. Digital video capabilities can be incorporated into a wide variety of devices, including digital televisions, digital live broadcasting systems, wireless broadcasting systems, personal digital assistants (PDAs), laptops or desktop computers, tablets, e-book readers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular or satellite wireless phones, so-called "smartphones," video conferencing equipment, video streaming devices, and so on. These devices allow video data to be processed and output for consumption. Digital video data comprises a large amount of data used to meet the needs of consumers and video providers. For example, consumers of video data expect the highest quality video with high fidelity, high resolution, and high frame rates. As a result, the large amount of video data required to meet these needs places a burden on the communication networks and equipment that process and store the video data. Digital video equipment can implement video decoding techniques to compress video data. Video decoding is performed according to one or more video decoding standards or formats. Examples of video decoding standards or formats include Universal Video Decoding (VVC), High-Efficiency Video Decoding (HEVC), Advanced Video Decoding (AVC), MPEG-2 Part 2 Decoding (MPEG stands for Moving Picture Experts Group), Equal Value Video Decoding (EVC), and proprietary video transcoders (transcoders) / formats, such as AOMedia Video 1 (AV1) developed by the Open Media Consortium. Video decoding typically uses predictive methods (e.g., inter-prediction, intra-prediction, etc.) that utilize redundancy present in video images or sequences. One goal of video decoding technology is to compress video data to a form using a lower bit rate while avoiding or minimizing video quality degradation. As more and more video services become available, there is a need for decoding technologies with better decoding efficiency. This document describes systems and techniques for processing video data. According to at least one example, a method for processing video is provided, comprising: acquiring an image; and determining at least one of the width and height of a film grain composite block of the image based on at least one of the width and height of the image. According to at least one other example, an apparatus for processing video data is provided, the apparatus comprising: at least one memory and at least one processor (e.g., implemented in a circuit) coupled to the at least one memory. The at least one processor is configured to: acquire video data including an image; determine the width of a film grain composite block of the image based on at least one of a width and a height of the image; determine the height of the film grain composite block of the image as one; determine the block size of the film grain composite block based on the determined width and height; and select a grain block based on the determined block size. As another example, a method for processing video data is provided. The method includes: obtaining video data including an image; determining the width of a film grain composite block of the image based on at least one of the width and height of the image; determining the height of the film grain composite block of the image to be one; determining the block size of the film grain composite block based on the determined width and height; and selecting a grain block based on the determined block size. In another example, a non-transitory computer-readable medium is provided, having instructions stored thereon that, when executed by at least one or more processors, cause the processors to: acquire video data including an image. The instructions also cause the processors to: determine the width of a film grain composite block of the image based on at least one of the width and height of the image; determine the height of the film grain composite block of the image to be one; determine the block size of the film grain composite block based on the determined width and height; and select a grain block based on the determined block size. As another example, an apparatus for processing video data is provided. The apparatus includes: a unit for acquiring video data including an image; a unit for determining the width of a film grain composite block of the image based on at least one of the width and height of the image; a unit for determining the height of the film grain composite block of the image to be one; a unit for determining the block size of the film grain composite block based on the determined width and height; and a unit for selecting a grain block based on the determined block size. In some embodiments, any of the aforementioned devices or apparatuses is, is part of, and / or includes: mobile devices (e.g., mobile phones or so-called "smartphones" or other mobile devices), wearable devices, extended reality devices (e.g., virtual reality (VR) devices, augmented reality (AR) devices, or mixed reality (MR) devices), cameras, personal computers, laptops, server computers, vehicles or computing devices or vehicle components, robotic devices or systems, televisions, or other devices. In some embodiments, these devices or apparatuses include one or more cameras for capturing one or more pictures, images, or frames. In some embodiments, these devices or apparatuses include displays for displaying one or more images, notifications, and / or other displayable data. In some embodiments, these devices or apparatuses may include one or more sensors (e.g., one or more inertial measurement units (IMUs), such as one or more gyroscopes, one or more accelerometers, any combination thereof, and / or other sensors). The content of this invention is not intended to determine the key or essential features of the claimed inventive subject matter, nor is it intended to be used alone to determine the scope of the claimed inventive subject matter. The inventive subject matter should be understood by referring to the appropriate portions of the entire specification of this patent, any or all of the drawings, and each claim. The foregoing and other features and embodiments will become more apparent from the following description, claims, and drawings. The following provides certain styles and embodiments of the content of this case. It will be apparent to those skilled in the art to which this invention pertains that some of these styles and embodiments can be applied independently, and some can be applied in combination. In the following description, specific details are set forth for purposes of explanation in order to provide a thorough understanding of the embodiments of this case. However, it will be apparent that various embodiments can be practiced without using these specific details. The drawings and description are not intended to be limiting. The following description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of this invention. Rather, the subsequent description of exemplary embodiments will provide those skilled in the art with a description of how to implement these exemplary embodiments. It should be understood that various changes can be made to the function and arrangement of the elements without departing from the spirit and scope of this invention as set forth in the appended claims. Film grain typically refers to random optical textures that can appear in processed photographic film. Because encoding film grain is costly, it can be characterized and removed during encoding via filtering. The characterized film grain can then be added back during decoding. The film grain of a video image can be characterized based on the average brightness value of a portion of the image (e.g., the current block). In many cases, the average brightness value of this portion is determined by reading at least a portion of each line of that portion of the image into a line buffer. Although line buffers are relatively common in image and video processing circuits, they occupy a relatively large amount of on-chip area and can therefore be relatively expensive to implement. To reduce the use of the line buffer, in some cases, the average brightness value of a portion of the image can be determined by reading a single line of that portion into the buffer and determining the average brightness value of that single line. In some cases, since the amount of data associated with a single line of that portion of the image is relatively small, the data associated with that single line of the image can be stored in any accessible memory without needing to be stored in the line buffer. In some cases, an average brightness value can be determined for each line of that portion of the image, and these average brightness values can be averaged to produce the average brightness value of that portion (e.g., the overall average brightness value). Video decoding equipment implements video compression techniques to efficiently encode and decode video data. Video compression techniques may include applying different prediction modes to reduce or eliminate inherent redundancy in video sequences. These prediction modes include spatial prediction (e.g., intra-frame prediction or intra-prediction), temporal prediction (e.g., inter-frame prediction or inter-prediction), inter-layer prediction (across different layers of video data), and / or other prediction techniques. A video transcoder can divide each frame of the original video sequence into multiple rectangular regions, which are called video blocks or decoding units (described in more detail below). Specific prediction modes can be used to encode these video blocks. Video blocks can be divided into one or more smaller blocks in one or more ways. Blocks may include decode tree blocks, prediction blocks, transform blocks, or other suitable blocks. Unless otherwise specified, the reference to "block" generally refers to such video blocks (e.g., decode tree blocks, decode blocks, prediction blocks, transform blocks, or other suitable blocks or sub-blocks that will be understood by one of ordinary skill in the art to which this invention pertains). Furthermore, each of these blocks may also be interchangeably referred to herein as a "unit" (e.g., decode tree unit (CTU), decode unit, prediction unit (PU), transform unit (TU), etc.). In some cases, a unit may refer to a decoded logic unit encoded in a bitstream, while a block may refer to a portion of the video frame buffer targeted by the program. For inter-prediction mode, the video transcoder searches for blocks similar to those encoded in a frame (or image) at another time location, referred to as a reference frame or reference image. The transcoder can limit the search to a certain spatial displacement from the block to be encoded. A two-dimensional (2D) motion vector, including horizontal and vertical displacement components, can be used to locate the best match. For intra-prediction mode, the video transcoder uses spatial prediction techniques to form predicted blocks based on data from previously encoded adjacent blocks within the same image. Video transcoders can determine prediction error. For example, prediction can be determined as the difference between the primitive values in the block being encoded and the predicted block. Prediction error can also be referred to as residual. Video transcoders can also apply a transform to the prediction error (e.g., Discrete Cosine Transform (DCT) or other suitable transform) to produce transform coefficients. After the transform, the video transcoder can quantize the transform coefficients. The quantized transform coefficients and motion vectors can be represented using syntax elements and, together with control information, form a decoded representation of the video sequence. In some cases, video transcoders can perform entropy decoding on the syntax elements, further reducing the number of bits required for its representation. A video decoder can use the syntax elements and control information discussed above to construct prediction data (e.g., prediction blocks) for decoding the current frame. For example, a video decoder can add the prediction blocks to the compressed prediction error. The video decoder can determine the compressed prediction error by weighting the transform basis function using quantized coefficients. The difference between the reconstructed frame and the original frame is called the reconstruction error. Film grain, or fine detail, is the random optical texture of processed photographic film. Encoding film grain noise in the DCT domain is expensive. Film Grain Characteristics (FGC) Supplemental Enhancement Information (SEI) messages are specified in AVC, HEVC, and VVC to provide decoders with a parametric model for film grain composition. Encoders can use the FGC SEI messages to characterize film grain present in the original source video material and removed by preprocessing filtering techniques. During post-processing, decoders can use the FGC SEI messages to analogize film grain on the decoded image for display purposes. The Society of Motion Picture and Television Engineers (SMPTE) Registered Publication Document (RDD) 5 provides a technical specification for film grain in video bitstreams (e.g., H.264 / AVC bitstreams). The entire contents of the SMPTE RDD 5 specification are incorporated herein by reference for all purposes and are provided in Annex A accompanying this document. Film grain synthesis can involve several challenges, which will be described in more detail below. This document describes systems, apparatuses, procedures (also referred to as methods), and computer-readable media (collectively referred to herein as "systems and techniques") for improving film grain synthesis. In some instances, these systems and techniques can provide resolution-self-adjusting film grain block size. Additionally or alternatively, in some instances, these systems and techniques can provide improvements to film grain databases. Additionally or alternatively, in some instances, these systems and techniques can provide texture pattern database generation. Additional details will be described herein. The systems and techniques described herein can be applied to any existing video transcoder, such as Universal Video Controller (VVC), High-Efficiency Video Controller (HEVC), Advanced Video Controller (AVC), Important Video Controller (EVC), VP9, AV1 format / transcoder, and / or other video decoding standards, transcoders, formats, etc. that are under development or will be developed. Figure 1 is a block diagram illustrating an example of a system 100 including an encoding device 104 and a decoding device 112. The encoding device 104 may be part of a source device, and the decoding device 112 may be part of a receiving device. The source device and / or receiving device may include electronic devices such as mobile or landline handsets (e.g., smartphones, cellular phones, etc.), desktop computers, laptops or notebooks, tablets, set-top boxes, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, Internet Protocol (IP) cameras, or any other suitable electronic devices. In some instances, the source device and receiving device may include one or more wireless transceivers for wireless communication. The decoding techniques described herein are applicable to video decoding in a variety of multimedia applications, including streaming video transmission (e.g., via the Internet), television broadcasting or transmission, encoding of digital video stored on data storage media, decoding of digital video stored on data storage media, or other applications. As used herein, the term decoding may refer to both encoding and / or decoding. In some instances, system 100 may support one-way or two-way video transmission to support applications such as video conferencing, video streaming, video replay, video broadcasting, gaming, and / or video telephony. Encoding device 104 (or encoder) can be used to encode video data using video decoding standards, formats, transcoders, or protocols to produce an encoded video bitstream. Examples of video decoding standards and formats / transcoders include ITU-T H.261, ISO / IEC MPEG-1 Vision, ITU-T H.262 or ISO / IEC MPEG-2 Vision, ITU-T H.263, ISO / IEC MPEG-4 Vision, ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC), including its Adjustable Video Decoding (SVC) and Multi-View Video Decoding (MVC) extensions, High-Efficiency Video Decoding (HEVC) or ITU-T H.265, and Universal Video Decoding (VVC) or ITU-T H.266. Various extensions of HEVC exist for multi-layer video decoding, including range and screen content decoding extensions, 3D video decoding (3D-HEVC), multi-view extensions (MV-HEVC), and adjustable extensions (SHVC). HEVC and its extensions were developed by the Joint Coordination Team for Video Decoding (JCT-VC), the Joint Coordination Team for the Development of 3D Video Decoding Extensions of the ITU-T Video Decoding Experts Group (VCEG) (JCT-3V), and the ISO / IEC Cinema Experts Group (MPEG). VP9, AOMedia Video 1 (AV1) developed by the Alliance for Open Media (AOMedia), and Essential Video Decoding (EVC) are other video decoding standards to which the technologies described herein can be applied. The techniques described herein can be applied to any existing video transcoder (e.g., High Efficiency Video Transcoder (HEVC), Advanced Video Transcoder (AVC), or other suitable existing video transcoders), and / or can be effective decoding tools for any video decoding standard under development and / or future video decoding standards (e.g., VVC) and / or other video decoding standards under development or to be developed. For example, the examples described herein can be performed using video transcoders such as VVC, HEVC, AVC, and / or their extensions. However, the techniques and systems described herein can also be applied to other decoding standards, transcoders, or formats, such as MPEG, JPEG (or other decoding standards for still images), EVC, VP9, AV1, their extensions, or other suitable decoding standards that are already available or not yet available or under development. For example, in some instances, encoding device 104 and / or decoding device 112 can operate according to proprietary video transcoders / formats, such as AV1, AVI extensions and / or subsequent versions of AV1 (e.g., AV2), or other proprietary formats or industry standards. Therefore, although the techniques and systems described herein may be described with reference to specific video decoding standards, those skilled in the art to which this invention pertains will understand that the description should not be construed as applicable only to that particular standard. Referring to Figure 1, video source 102 can provide video data to encoding device 104. Video source 102 may be part of a source device or part of a device other than a source device. Video source 102 may include video capturing devices (e.g., cameras, camera phones, video phones, etc.), video files containing stored video, video servers or content providers providing video data, video feed interfaces for receiving video from video servers or content providers, computer graphics systems for generating computer graphics video data, combinations of such sources, or any other suitable video source. Video data from video source 102 may include one or more input pictures or frames. A picture or frame is a still image and, in some cases, is part of the video. In some instances, the data from video source 102 may be a still image that is not part of the video. In HEVC, VVC, and other video decoding specifications, a video sequence may include a series of pictures. A picture may include three sampling arrays, denoted as SL, SCb, and SCr, respectively. SL is a two-dimensional array of luminance samples, SCb is a two-dimensional array of Cb chrominance samples, and SCr is a two-dimensional array of Cr chrominance samples. Chrominance sampling may also be referred to herein as "chrominance" sampling. A primitive may represent all three components (luminance and chrominance samples) at a given location in the picture array. In other cases, a picture may be monochrome and may consist only of an array of luminance samples; in this case, the terms primitive and sampling may be used interchangeably. The same techniques described herein, which involve individual sampling for illustrative purposes, can be applied to primitives (e.g., all three sampled components at a given location in the picture array). The same techniques described herein, which are for illustrative purposes and involve primitives (e.g., all three sampled components at a given location in an image array), can be applied to individual sampling. The encoder engine 106 (or encoder) of the encoding device 104 encodes the video data to produce an encoded video bitstream. In some instances, the encoded video bitstream (or "video bitstream" or "bitstream") is a series of one or more decoded video sequences. The decoded video sequence (CVS) includes a series of access units (AUs) that begin with an AU that has a random access point picture in the base layer and possesses certain attributes, up to but not including the next AU that has a random access point picture in the base layer and possesses certain attributes. For example, certain attributes of the random access point picture that initiates the CVS may include a RASL picture flag equal to 1 (e.g., NoRaslOutputFlag). Otherwise, a random access point picture (with a RASL flag equal to 0) will not initiate the CVS. An access unit (AU) includes one or more decoded pictures and control information corresponding to the decoded pictures that share the same output time. The decoded slices of an image are encapsulated at the bitstream level into data units called Network Abstraction Layer (NAL) units. For example, an HEVC video bitstream may include one or more CVSs that include NAL units. Each NAL unit has a NAL unit header. In one instance, the header for H.264 / AVC is a single byte (except for multi-layer extensions), while the header for HEVC is two bytes. The syntax elements in the NAL unit header use specified bits and are therefore visible to all types of systems and transport layers, such as transport streams, Real-Time Transport (RTP) protocols, file formats, etc. The HEVC standard contains two types of NAL units: Video Decoding Layer (VCL) NAL units and non-VCL NAL units. VCL NAL units contain decoded image data that forms the decoded video bitstream. For example, the bit sequence forming the decoded video bitstream exists within a VCL NAL unit. A VCL NAL unit may include a slice or fragment of the decoded image data (described below), and non-VCL NAL units contain control information associated with one or more decoded images. In some cases, NAL units may be referred to as packets. A HEVC AU includes VCL NAL units containing decoded image data and corresponding non-VCL NAL units (if any). Among other information, non-VCL NAL units may also contain parameter sets with high-level information related to the encoded video bitstream. For example, parameter sets may include Video Parameter Sets (VPS), Sequence Parameter Sets (SPS), and Picture Parameter Sets (PPS). In some cases, each slice or other portion of the bitstream may reference a single active PPS, SPS, and / or VPS to allow the decoding device 112 to access information that can be used to decode the slice or other portion of the bitstream. NAL units may contain bit sequences that form a decoded representation of video data (e.g., an encoded video bitstream, a CVS of a bitstream, etc.), such as a decoded representation of an image in a video. Encoder engine 106 generates a decoded representation of an image by dividing each image into multiple slices. A slice is independent of other slices, allowing information within a slice to be decoded without relying on data from other slices within the same image. A slice includes one or more slice fragments, including independent slice fragments and (if present) one or more dependent slice fragments that depend on previous slice fragments. Subsequently, in HEVC, the slice is divided into code tree blocks (CTBs) for luma sampling and chroma sampling. The luma-sampled CTB and one or more chroma-sampled CTBs, along with the sampling syntax, are called code tree units (CTUs). CTUs can also be called "tree blocks" or "maximum decoding units" (LCUs). The CTU is the basic processing unit in HEVC encoding. A CTU can be divided into multiple code tree units (CUs) of different sizes. Each CU contains luma and chroma sample arrays and is called a code tree block (CB). Luminance and chrominance CBs can be further divided into prediction blocks (PBs). A PB is a sampling block of the luminance or chrominance component that uses the same motion parameters for inter-prediction or intra-block copy (IBC) prediction (when available or enabled). A luminance PB and one or more chrominance PBs, along with their associated syntax, form a prediction unit (PU). For inter-prediction, a set of motion parameters (e.g., one or more motion vectors, reference indices, etc.) is signaled in the bitstream of each PU and used for inter-prediction of the luminance PB and one or more chrominance PBs. Motion parameters can also be referred to as motion information. CBs can also be divided into one or more transform blocks (TBs). A TB represents a square block of samples of the color components on which a residual transform (e.g., in some cases the same two-dimensional transform) is applied to decode the prediction residual signal. A transform unit (TU) represents the TB of luminance and chrominance samples, along with the corresponding syntax elements. Transform decoding is described in more detail below. The size of the CU corresponds to the size of the decoding mode, and its shape can be square. For example, the size of the CU can be 8×8 samples, 16×16 samples, 32×32 samples, 64×64 samples, or any other suitable size up to the size of the corresponding CTU. The phrase "N×N" is used herein to represent the primitive dimensions (e.g., 8 primitives × 8 primitives) of the vertical and horizontal dimensions of the video block. Primitives in the block can be arranged in rows and columns. In some implementations, the block may not have the same number of primitives in the horizontal direction as it does in the vertical direction. The syntax data associated with the CU can describe, for example, dividing the CU into one or more PUs. The partitioning pattern can differ between intra-predictive mode coding and inter-predictive mode coding of the CU. PUs can be partitioned into non-square shapes. The syntax data associated with the CU can also describe, for example, dividing the CU into one or more TUs according to the CTU. The shape of the TU can be square or non-square. According to the HEVC standard, transform units (TUs) can be used to perform transforms. The TU can be different for different CUs. The size of the TU can be determined based on the size of the PU within a given CU. The size of the TU can be the same as or smaller than the PU. In some instances, a quadtree structure called a residual quadtree (RQT) can be used to subdivide the residual samples corresponding to the CU into smaller units. The leaf nodes of the RQT can correspond to the TU. The primitive differences associated with the TU can be transformed to produce transform coefficients. Subsequently, the transform coefficients can be quantized by the encoder engine 106. Once the video data is divided into Units (CUs), the encoder engine 106 uses a prediction pattern to predict each Unit (PU). The prediction unit or block is then subtracted from the original video data to obtain a residual (as shown below). For each CU, the prediction pattern can be signaled within the bitstream using syntax data. The prediction pattern can include intra-picture prediction (or intra-image prediction) or inter-picture prediction (or inter-picture prediction). Intra-picture prediction utilizes the correlation between spatially adjacent samples within a picture. For example, in the case of intra-picture prediction, each PU is predicted by using, for example, DC prediction to find the average value of the PU, using planar prediction to fit the planar area to the PU, using orientation prediction to extrapolate from adjacent data, or using any other suitable type of prediction based on adjacent image data in the same picture. Inter-picture prediction uses the temporal correlation between pictures to derive motion-compensated predictions for image sample blocks. For example, in the case of inter-picture prediction, motion-compensated predictions are used to predict each PU from image data in one or more reference pictures (in output order before or after the current picture). For example, a decision can be made at the CU level whether to use inter-picture or intra-picture prediction to decode a picture region. Encoder engine 106 and decoder engine 116 (described in more detail below) can be configured to operate according to VVC. According to VVC, the video decoder (e.g., encoder engine 106 and / or decoder engine 116) divides the image into a plurality of decoder tree units (CTUs) (where the CTB of luminance sampling and one or more CTBs of chrominance sampling, as well as the sampling syntax, are referred to as CTUs). The video decoder 200 can partition the CTUs according to a tree structure (e.g., a quadtree-binary tree (QTBT) structure or a multi-type tree (MTT) structure). The QTBT structure eliminates the concept of multiple partition types, such as the separation between CUs, PUs, and TUs in HEVC. The QTBT structure includes two levels: a first level partitioned according to quadtree partitioning and a second level partitioned according to binary tree partitioning. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary tree correspond to decoder units (CUs). In the MTT partitioning structure, blocks can be divided using quadtree partitioning, binary tree partitioning, and one or more types of ternary tree partitioning. Ternary tree partitioning is a partitioning method that divides a block into three sub-blocks. In some instances, ternary tree partitioning divides a block into three sub-blocks without using a center to partition the original block. Partition types in MTT (e.g., quadtree, binary tree, and ternary tree) can be symmetric or asymmetric. When operating according to the AV1 transcoder, the video transcoder engine 106 and the video decoder engine 116 can be configured to decode video data in blocks. In AV1, the largest decoded block that can be processed is called a superblock. In AV1, a superblock can be a 128x128 luminance sample or a 64x64 luminance sample. However, in subsequent video decoding formats (e.g., AV2), the superblock can be defined by different (e.g., larger) luminance sample sizes. In some instances, the superblock is the top level of a block quadtree. The video transcoder engine 106 can also divide the superblock into smaller decoded blocks. The video transcoder engine 106 can divide the superblock and other decoded blocks into smaller blocks using square or non-square partitions. Non-square blocks can include N / 2xN, NxN / 2, N / 4xN, and NxN / 4 blocks. The video transcoder engine 106 and the video decoder engine 116 can perform separate prediction and transformation procedures for each decoded block. AV1 also defines video data tiles. A tile is a rectangular array of superblocks that can be decoded independently of other tiles. That is, the video transcoder engine 106 and the video decoder engine 116 can encode and decode the decoding blocks within a tile separately without using video data from other tiles. However, the video transcoder engine 106 and the video decoder engine 116 can perform filtering across tile boundaries. The tile size can be uniform or non-uniform. Tile-based decoding enables parallel processing and / or multithreading of the encoder and decoder implementations. In some instances, a video decoder may use a single QTBT or MTT structure to represent each of the luminance and chrominance components, while in other instances, a video decoder may use two or more QTBT or MTT structures, for example, one QTBT or MTT structure for the luminance component and another QTBT or MTT structure for the two chrominance components (or two QTBT and / or MTT structures for the respective chrominance components). The video decoder can be configured to use quadtree partitioning, QTBT partitioning, MTT partitioning, superblock partitioning, or other partitioning structures. In some instances, slice types are assigned to one or more slices of an image. Slice types include intra-decoded slices (I-slices), inter-decoded P-slices, and inter-decoded B-slices. An I-slice (intra-decoded frame, independently decodable) is a slice of an image decoded solely by intra-prediction and is therefore independently decodable because an I-slice only requires data within the frame to predict any prediction unit or prediction block of the slice. A P-slice (one-way prediction frame) is a slice of an image that can be decoded using both intra-prediction and one-way inter-prediction. Each prediction unit or prediction block within a P-slice is decoded using either intra-prediction or inter-prediction. When inter-prediction is applied, the prediction unit or prediction block is predicted by only one reference image, and therefore the reference sample comes only from one reference region of a frame. A B-slice (two-way prediction frame) is a slice of an image that can be decoded using both intra-prediction and inter-prediction (e.g., two-way or one-way prediction). A prediction unit or block for a B-slice can be bidirectionally predicted from two reference images, where each image contributes a reference region and the sample sets of the two reference regions are weighted (e.g., with equal weights or different weights) to produce the prediction signal for the bidirectional prediction block. As mentioned earlier, slices of an image can be decoded independently. In some cases, an image can be decoded into only one slice. As mentioned earlier, intra-image prediction for an image utilizes the correlation between spatially adjacent samples within the image. There are multiple intra-prediction modes (also referred to as "intra-modes"). In some instances, intra-prediction for a luma patch includes 35 modes, including planar modes, DC modes, and 33 angular modes (e.g., diagonal intra-prediction modes and adjacent angular modes). The 35 intra-prediction modes are indexed as shown in Table 1 below. In other instances, more intra-modes can be defined, including prediction angles that may not yet be represented by the 33 angular modes. In other instances, the prediction angles associated with angular modes may differ from those used in HEVC. Table 1 – Specifications for Internal Prediction Patterns and Related Names Inter-image prediction uses the temporal correlation between images to derive motion-compensated predictions for the current block in the image sample. Using a translational motion model, the position of the block in the previously decoded image (reference image) is indicated by motion vectors. ,in Specify the horizontal displacement, and Specifies the vertical displacement of the reference block relative to the position of the current block. In some cases, the motion vector ( The motion vector can have integer sampling precision (also known as integer precision), in which case the motion vector points to the integer primitive grid (or integer primitive sampling grid) of the reference frame. In some cases, the motion vector ( Motion vectors can have fractional sampling precision (also known as fractional primitive precision or non-integer precision) to more accurately capture the motion of underlying objects, without being limited by the integer primitive grid of the reference frame. The accuracy of the motion vector can be represented by the quantization level of the motion vector. For example, the quantization level can be integer precision (e.g., 1 primitive) or fractional primitive precision (e.g., 1 / 4 primitive, 1 / 2 primitive, or other sub-primitive values). When the corresponding motion vector has fractional sampling precision, interpolation is applied to the reference picture to output the prediction signal. For example, the available samples at integer positions can be filtered (e.g., using one or more interpolation filters) to estimate the values at fractional positions. The previously decoded reference picture is indicated by a reference index (refIdx) used for the reference picture list. The motion vector and the reference index can be referred to as motion parameters. Two types of inter-picture prediction can be performed, including one-way prediction and two-way prediction. For inter-prediction using bidirectional prediction (also known as bidirectional inter-prediction), two sets of motion parameters ( and This is used to generate two motion-compensated predictions (from the same reference image or possibly from different reference images). For example, in the case of bidirectional prediction, each prediction block uses two motion-compensated prediction signals and generates B prediction units. These two motion-compensated predictions are then combined to obtain the final motion-compensated prediction. For example, the two motion-compensated predictions can be combined by averaging. In another instance, weighted prediction can be used, in which different weights can be applied to each motion-compensated prediction. The reference images available for bidirectional prediction are stored in two separate lists, denoted as List 0 and List 1. Motion parameters can be exported at the encoder using a motion estimation procedure. In the case of using one-way prediction for inter-prediction (also known as one-way inter-prediction), the set of motion parameters ( This is used to generate motion-compensated predictions from a reference image. For example, in the case of unidirectional prediction, each prediction block uses at most one motion-compensated prediction signal and generates P prediction units. The prediction unit (PU) may include data related to the prediction process (e.g., motion parameters or other suitable data). For example, when encoding the PU using intra-prediction, the PU may include data describing the intra-prediction patterns used for the PU. As another example, when encoding the PU using inter-prediction, the PU may include data defining the motion vectors used for the PU. The data defining the motion vectors used for the PU may describe, for example, the horizontal components of the motion vectors (…). ), the vertical component of the motion vector ( The resolution of the motion vector (e.g., integer precision, quarter-key precision, or eighth-key precision), the reference picture to which the motion vector points, the reference index, the list of reference pictures for the motion vector (e.g., list 0, list 1, or list C), or any combination thereof. AV1 includes two common techniques for encoding and decoding blocks of video data. The two common techniques are intra-prediction (e.g., intra-prediction or spatial prediction) and inter-prediction (e.g., inter-frame prediction or temporal prediction). In the context of AV1, when using intra-prediction mode to predict blocks of the current frame of video data, the video transcoder engine 106 and the video decoder engine 116 do not use video data from other frames of the video data. For most intra-prediction modes, the video encoding device 104 encodes the block of the current frame based on the difference between the sampled value in the current block and the predicted value generated from a reference sample in the same frame. The video encoding device 104 determines the predicted value generated from the reference sample based on the intra-prediction mode. After performing prediction using intra-prediction and / or inter-prediction, encoding device 104 can perform transformation and quantization. For example, after prediction, encoder engine 106 can calculate a residual value corresponding to the PU. The residual value can include primitive differences between the decoded current block (PU) and the prediction block used to predict the current block (e.g., a prediction version of the current block). For example, after generating a prediction block (e.g., issuing inter-prediction or intra-prediction), encoder engine 106 can generate a residual block by subtracting the prediction block generated by the prediction unit from the current block. The residual block includes a set of primitive differences that quantize the differences between the primitive values of the current block and the primitive values of the prediction block. In some instances, the residual block can be represented in a two-dimensional block format (e.g., a two-dimensional matrix or array of primitive values). In such instances, the residual block is a two-dimensional representation of the primitive values. Block transforms are used to transform any residual data that may remain after prediction is performed. These block transforms can be based on discrete cosine transform, discrete sine transform, integer transform, wavelet transform, other suitable transform functions, or any combination thereof. In some cases, one or more block transforms (e.g., of sizes 32×32, 16×16, 8×8, 4×4, or other suitable sizes) can be applied to the residual data in each CU. In some embodiments, TUs can be used for transform and quantization procedures implemented by encoder engine 106. A given CU having one or more PUs can also include one or more TUs. As described further in detail below, block transforms can be used to transform residual values into transform coefficients, and subsequently, TUs can be used to quantize and scan the residual values to produce serialized transform coefficients for entropy decoding. In some embodiments, after intra-prediction or inter-prediction decoding using the PU of the CU, the encoder engine 106 can compute residual data of the TU of the CU. The PU may include primitive data in the spatial domain (or primitive domain). The TU may include coefficients in the transform domain after applying a block transform. As mentioned above, the residual data may correspond to the primitive difference between the primitives of the uncoded image and the predicted value corresponding to the PU. The encoder engine 106 can form a TU that includes the residual data of the CU, and can subsequently transform the TU to produce transform coefficients for the CU. The encoder engine 106 can perform quantization of the transform coefficients. Quantization provides further compression by reducing the amount of data used to represent the coefficients. For example, quantization can reduce the bit depth associated with some or all of the coefficients. In one instance, a coefficient with an n-bit value can be rounded to an m-bit value during quantization, where n is greater than m. Once quantization is performed, the decoded video bitstream includes quantized transform coefficients, prediction information (e.g., prediction patterns, motion vectors, block vectors, etc.), partitioning information, and any other suitable data, such as other syntax data. Subsequently, the different elements of the decoded video bitstream can be entropy-decoded by encoder engine 106. In some instances, encoder engine 106 can scan the quantized transform coefficients using a predefined scan order to produce a serialized vector that can be entropy-encoded. In some instances, encoder engine 106 can perform a self-adjusting scan. After scanning the quantized transform coefficients to form a vector (e.g., a one-dimensional vector), encoder engine 106 can entropy-encode the vector. For example, encoder engine 106 can use context-adjusting variable-length decoding, context-adjusting binary arithmetic decoding, syntax-based context-adjusting binary arithmetic decoding, probabilistic interval partitioning entropy decoding, or another suitable entropy coding technique. The output 110 of the encoding device 104 can transmit the NAL units constituting the encoded video bitstream data to the decoding device 112 of the receiving device via the communication link 120. The input 114 of the decoding device 112 can receive the NAL units. The communication link 120 may include a channel provided by a wireless network, a wired network, or a combination of wired and wireless networks. The wireless network may include any wireless interface or combination of wireless interfaces, and may include any suitable wireless network (e.g., the Internet or other wide area networks, packet-based networks, WiFi). TM Radio Frequency (RF), Ultra Wideband (UWB), WiFi Direct, Cellular, Long Term Evolution (LTE), WiMax TM Wired networks can include any wired interface (e.g., fiber optic, Ethernet, powerline Ethernet, Ethernet over coaxial cable, digital signal line (DSL), etc.). Wired and / or wireless networks can be implemented using a variety of devices such as base stations, routers, access points, bridges, gateways, switches, etc. Encoded video bitstream data can be modulated according to communication standards (e.g., wireless communication protocols) and transmitted to the receiving device. In some instances, encoding device 104 may store encoded video bitstream data in storage device 108. Output 110 may retrieve the encoded video bitstream data from encoder engine 106 or from storage device 108. Storage device 108 may include any of a variety of distributed or local access data storage media. For example, storage device 108 may include hard disks, storage disks, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. Storage device 108 may also include a picture buffer (DPB) for storing decoded reference pictures for inter-prediction. In another instance, storage device 108 may correspond to a file server or another intermediate storage device that may store encoded video generated by a source device. In this case, receiving device including decoding device 112 may access the stored video data from the storage device via data streaming or download. The file server may be any type of server capable of storing encoded video data and sending such encoded video data to the receiving device. The instance file server includes a network server (e.g., for a website), an FTP server, a network additional storage (NAS) device, or a local disk drive. The receiving device can access the encoded video data via any standard data connection, including an internet connection. This can include wireless channels (e.g., Wi-Fi connections), wired connections (e.g., DSL, cable modems, etc.), or combinations thereof, suitable for accessing encoded video data stored on the file server. Transmission of the encoded video data from storage device 108 can be data streaming, download transmission, or a combination thereof. The input 114 of the decoding device 112 receives encoded video bitstream data and can provide the video bitstream data to the decoder engine 116 or to the storage device 118 for later use by the decoder engine 116. For example, the storage device 118 may include a DPB for storing reference pictures for inter-prediction. A receiving device including the decoding device 112 can receive the encoded video data to be decoded via the storage device 108. The encoded video data may be modulated according to a communication standard (e.g., a wireless communication protocol) and transmitted to the receiving device. The communication medium used to transmit the encoded video data may include any wireless or wired communication medium, such as radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include a router, a switch, a base station, or any other device that facilitates communication from the source device to the receiving device. Decoder engine 116 can decode the encoded video bitstream data via entropy decoding (e.g., using an entropy decoder) and extract elements constituting one or more decoded video sequences of the encoded video data. Decoder engine 116 can then rescale and perform an inverse transform on the encoded video bitstream data. The residual data is then passed to the prediction stage of decoder engine 116. Decoder engine 116 then predicts the current block of primitives (e.g., PU). In some instances, the prediction is added to the output of the inverse transform (residual data). Video decoding device 112 can output decoded video to video destination device 122, which may include a display or other output device for displaying the decoded video data to a consumer of the content. In some embodiments, video destination device 122 may be part of a receiving device that includes decoding device 112. In some embodiments, video destination device 122 may be part of a separate device other than the receiving device. In some embodiments, the video encoding device 104 and / or the video decoding device 112 may be integrated with the audio encoding device and the audio decoding device, respectively. The video encoding device 104 and / or the video decoding device 112 may also include other hardware or software required to implement the above-described decoding technology, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic units, software, hardware, firmware, or any combination thereof. The video encoding device 104 and the video decoding device 112 may be integrated as part of a combined encoder / decoder (transcoder) in the respective device. The example system shown in Figure 1 is an illustrative example that can be used herein. The techniques used to process video data using the techniques described herein can be implemented by any digital video encoding and / or decoding device. Although generally, the techniques described herein are implemented by video encoding or video decoding devices, these techniques can also be implemented by a combined video transcoder-decoder commonly referred to as a "CODEC". Furthermore, the techniques described herein can also be implemented by a video preprocessor. The source device and receiving device are merely examples of such decoding devices, where the source device generates decoded video data for transmission to the receiving device. In some instances, the source device and receiving device can operate in a substantially symmetrical manner, such that each of these devices includes video encoding and decoding components. Therefore, the example system can support one-way or two-way video transmission between video devices, for example, for video streaming, video replay, video broadcasting, or video telephony. Extensions to the HEVC standard include the Multi-View Video Decoding Extension (MV-HEVC) and the Adjustable Video Decoding Extension (SHVC). MV-HEVC and SHVC extensions share the concept of layered decoding, where different layers are included in the encoded video bitstream. Each layer in the decoded video sequence is addressed by a unique layer identifier (ID). The layer ID may exist in the header of a NAL cell to identify the layer associated with that NAL cell. In MV-HEVC, different layers typically represent different views of the same scene in the video bitstream. In SHVC, different adjustable layers are provided that represent the video bitstream at different spatial resolutions (or picture resolutions) or different reconstruction fidelities. An adjustable layer may include a base layer (layer ID = 0) and one or more enhancement layers (layer IDs = 1, 2, ..., n). The base layer may conform to the first version of the HEVC profile and represents the lowest available layer in the bitstream. Compared to the base layer, enhancement layers offer increased spatial resolution, temporal resolution, or playback rate and / or reconstruction fidelity (or quality). Enhancement layers are hierarchically organized and may (or may not) depend on lower layers. In some instances, a single standard transcoder can be used to decode different layers (e.g., encoding all layers using HEVC, SHVC, or other decoding standards). In other instances, multi-standard transcoders can be used to decode different layers. For example, the base layer can be decoded using AVC, while one or more enhancement layers can be decoded using SHVC and / or MV-HEVC extensions of the HEVC standard. In summary, a layer comprises a set of VCL NAL units and a corresponding set of non-VCL NAL units. Specific layer ID values are assigned to NAL units. Layers can be hierarchical in the sense that a layer can depend on lower layers. A layer set refers to a self-contained series of layers represented in a bitstream, meaning that layers within a layer set can depend on other layers in the layer set within the decoding process, but not on any other layers used for decoding. Therefore, layers within a layer set can form independent bitstreams that can represent video content. A layer set can be obtained from another bitstream via operations of a sub-bitstream extractor. When the decoder wants to operate based on certain parameters, the layer set can correspond to the layer set to be decoded. As mentioned earlier, the HEVC bitstream includes a set of NAL units, which includes VCL NAL units and non-VCL NAL units. VCL NAL units contain decoded picture data that forms the decoded video bitstream. For example, the bit sequence forming the decoded video bitstream exists in the VCL NAL units. Among other information, non-VCL NAL units may also contain parameter sets that have high-level information related to the encoded video bitstream. For example, parameter sets may include a Video Parameter Set (VPS), a Sequence Parameter Set (SPS), and a Picture Parameter Set (PPS). Examples of objectives for parameter sets include bit rate efficiency, error recovery capability, and providing a system-level interface. Each slice references a single active PPS, SPS, and VPS to access information that the decoding device 112 can use to decode the slice. Identifiers (IDs) can be decoded for each parameter set, including VPS ID, SPS ID, and PPS ID. An SPS includes an SPS ID and a VPS ID. The PPS includes a PPS ID and an SPS ID. Each slice header includes a PPS ID. Using the ID, the set of active parameters can be identified for a given slice. The PPS includes information applicable to all slices within a given image. Therefore, all slices in an image reference the same PPS. Slices in different images can also reference the same PPS. The SPS contains information applicable to all images within the same decoded video sequence (CVS) or bitstream. As mentioned earlier, a decoded video sequence (CVS) is a series of access units (AUs) that begin with an AU in the base layer that has a random access point image (e.g., an Instant Decoding Reference (IDR) image or a BLA image, or other suitable random access point image) and certain attributes (as described above), up to but not including the next AU in the base layer that has a random access point image and certain attributes (or the end of the bitstream). The information in the SPS may not change between images within the decoded video sequence. Images within a decoded video sequence can use the same SPS. The VPS includes information applicable to all layers within the decoded video sequence or bitstream. The VPS includes a syntax structure with syntax elements applicable to the entire decoded video sequence. In some embodiments, the VPS, SPS, or PPS may be transmitted in-band along with the encoded bitstream. In some embodiments, the VPS, SPS, or PPS may be transmitted out-of-band in a separate transmission, distinct from the NAL unit containing the decoded video data. This case can be broadly referred to as "transmitting by signal," which refers to certain information, such as syntax elements. The term "transmitting by signal" can generally refer to the communication of the values of syntax elements and / or other data used to decode encoded video data. For example, video encoding device 104 can transmit the values of syntax elements in a bitstream by signal. Generally, transmitting by signal means generating values in a bitstream. As mentioned above, video source 102 can transmit the bitstream to video destination device 122 substantially immediately or not immediately, for example, when storing syntax elements in storage device 108 for later retrieval by video destination device 122. Video bitstreams may also include Supplemental Enhancement Information (SEI) messages. For example, an SEI NAL unit can be part of the video bitstream. In some cases, SEI messages may contain information that is not required by the decoding process. For example, the information in the SEI message may not be necessary for the decoder to decode the video images in the bitstream, but the decoder can use the information to improve the display or processing of the images (e.g., the decoded output). The information in the SEI message can be embedded relay data. In an illustrative example, a decoder-side entity can use the information in the SEI message to improve the visibility of the content. In some cases, certain application standards may mandate the presence of such SEI messages in the bitstream to bring quality improvements to all application-compliant devices (e.g., frame-encapsulated SEI message bearers for frame-compatible planar stereoscopic 3DTV video formats, where each frame of the video carries an SEI message, handling restoring point SEI messages, using pan-scan scanning rectangle SEI messages in DVB, and many other examples). As mentioned earlier, film grain or fine detail is a random optical texture of processed photographic film, and encoding film grain noise (e.g., in the DCT domain) can be costly. Encoding device 104 (or other device) may send film grain characteristic (FGC) messages (e.g., as specified in AVC, HEVC, and VVC) to decoding device 112. The FGC message provides decoding device 112 with a parametric model for film grain composition. Encoding device 104 can use the FGC message (e.g., by signaling information in the FGC message) to characterize film grain present in the original source video material and removed by preprocessing filtering techniques. Post-processing at decoding device 112 can use the FGC SEI message to analogize film grain on the decoded image for display purposes. The FGC SEI message enables the encoding device 104 to signal different film grain analog models, blending modes, bit depths, transmission characteristics, and chroma processing options. Figure 2 is a diagram 200 illustrating the film grain composition (e.g., analog and blending) workflow for SMPTE RDD 5. The workflow can be accomplished via the following steps (or any combination thereof in any suitable order): 1) Generating a database 202 of texture patterns. In one instance, database 202 may include a set of texture patterns (e.g., up to 169 64x64 texture patterns), each texture pattern having a different combination of horizontal and vertical cutoff frequencies; 2) determining the intensity range to which each current block (e.g., the 8x8 current block (PU) being decoded) from decoder 214 in the decoded image belongs by comparing a representative brightness value of each current block (e.g., by determining the average 204 brightness value of an 8x8 current block) with the upper and lower limits of the intensity range transmitted in the FGC SEI message; 3) selecting a specific particle block (e.g., a specific 64x64 particle block) 206 from the database based on the cutoff frequency indicated for the corresponding intensity range. Horizontal and vertical offsets are then generated within the selected particle pattern (e.g., the selected 64x64 particle pattern), for example using a pseudo-random procedure 208. A particle block specified by the offset of the selected particle pattern is then selected (e.g., an 8x8 particle block specified by the offset relative to the 64x64 particle pattern). 4) Adjust the sampled values of the selected particle block (e.g., the selected 8x8 particle block) based on the particle intensity indicated for the corresponding intensity range, and remove the vertical edges of the particle blocks (e.g., remove the vertical edges of block 210 of the 8x8 particle block). 5) Add the sampled values of 212 of the particle block and the corresponding decoded image 216 of the current block to produce a particle blending output image 218. JVET-W0095 (ISO / IEC JTC 1 / SC 29 JVET-W0095 to Sean McCarthy et al., "AHG9: Fixed-point grain blending process for film grain characteristics SEI message", July 2021) proposes modifications to the SMPTE RDD 5 procedure. The entire contents of JVET-W0095 are incorporated herein by reference for all purposes and are provided in Appendix B accompanying this document. According to the proposal in JVET-W0095, the film grain size will be increased from the fixed 8x8 size in SMPTE RDD 5 to 16x16 for resolutions greater than 1920x1080 and up to 3840x2160 (4K), and to 32x32 for resolutions higher than 4K (including 8K). It can be asserted that using larger film grain sizes to achieve higher resolutions reduces implementation complexity and keeps grain pattern size proportionally consistent across 2K, 4K, and 8K resolutions. The RDD 5 approach and the proposed changes to JVET-W0095 for hardware implementations present potential challenges. For example, one challenge is that calculating the average brightness value of the current block requires line buffers in the implementation, and the larger the current block size, the more line buffers are needed. Figure 300 shows an example of line buffers required for 8x8 or 16x16 block film grain synthesis. As shown, the 8x8 current block 302 requires eight line buffers (shown as line buffers 304A 0 to 7), while the 16x16 current block 306 requires sixteen line buffers 304B (collectively referred to as 304) (shown as line buffers 304B 0 to 15). Line buffers 304 are a typical and primary on-chip memory design for image / video processing. Line buffers 304 typically occupy a large on-chip circuit area. Reducing the hardware cost of line buffers 304 through efficient design is important. Another challenge is that the film grain library (up to 169 64x64 grain patterns) is approximately 70 kilobits (KB) in size, which is also a high cost for hardware implementation. The film grain library is a combination of horizontal and vertical cutoff frequencies. The current grain library supports a maximum of 13 horizontal and vertical cutoff frequencies. We will explore tradeoffs between library size and subjective quality to simplify hardware implementation. Another challenge is that the variable fgCoeffs
[12]
[12] [i][j] proposed in JVET-W0095 is only filled with 59x59 instead of 64x64 pseudo-random numbers, which may not cover all frequencies. According to JVET-W0095, the variable derivation is as follows: The variable fgCutFreqH[h] is set to equal to ((h + 3) << 2) – 1, where h = 0..12. The variable fgCutFreqV[v] is set to equal to ((v + 3) << 2) – 1, where v = 0..12. The variable fgCoeffs[h][v][i][j] is initially set to equal to 0, where h = 0..12, v = 0..12, i = 0..63, j = 0..63, and is derived as follows: for(h = 0; h < 13, h++) { for(v = 0; v < 13, v++) { prngVal = SeedLUT(h + 13 * v) for(j = 0; j <= fgCutFreqV[ v ] ; j++ ) { for( i = 0; i <= fgCutFreqH[ h ] ; i + = 4 ) { for( k = 0; k < 4; k++ ) fgCoeffs[ h ][ v ][ i + k ][ j ] = gaussianLUT[ ( prngVal + k ) % 2048 ] prngVal = Prng( prngVal )}} fgCoeffs[ h ][ v ][ 0 ][ 0 ] = 0}} Film grain relay data used with AV1 is transmitted via signal via film grain parameter syntax (defined in the "AV1 Bitstream & Decoding Process Specification," Open Media Consortium, version 1.0.0, Errata 1, January 18, 2019, the entire contents of which are incorporated herein by reference and for all purposes), and film grain compositing is a mandatory part of post-processing. If film grain parameters are present in the bitstream, the film grain compositing procedure is invariably invoked, producing output video with film grain. Although film grain compositing is optional in AVC, HEVC, and VVC, the decoder may not apply film grain compositing, even if FGC SEI messages are present in the bitstream. One use case for film grain is to provide enhanced subjective quality for certain types of video content at a lower bitrate by adding film grain noise in post-production to suppress compression artifacts. In such cases, the encoder may expect film grain compositing to be performed on the decoder side, which in some cases can only be achieved by forcing film grain compositing through some means. In some cases, film grain relay data is carried or contained in one or more SEI messages associated with a specific bitstream. In this case, the decoder may need to scan all SEI messages to determine whether film grain relay data exists for the associated bitstream. In some instances, certain film grain relay data may be carried by users registered with a recommended ITU-T T.35 SEI message having a specific ITU-T T.35 code. In such instances, the decoder may need to scan all T.35 codes to determine whether film grain relay data exists. Indicators of film grain relay data availability will be helpful for the decoder's parsing process. As previously described, this paper describes systems and techniques for improving film grain composition. In some cases, these systems and techniques can provide resolution-self-adjusting film grain composition block sizes. For example, since the height of the film grain composition block is related to the number of line buffers, a resolution-self-adjusting block method is provided to allow for varying the height and width of the film grain composition block, depending on the image height and width or the total number of image primitive samples, or a combination thereof. In some cases, the value of the film grain composition block height should be in the range of 1 to 8, inclusive. Therefore, the maximum number of line buffers used is the same as in the RDD 5 procedure. In such cases, the value of the film grain composition block width should be in the range of 8 to W, inclusive, where W is the maximum width of the corresponding grain pattern. Figures 4A and 4B are flowcharts illustrating a procedure 400 for film grain composition according to the present invention. In the example procedure 400, the height of the film grain composition block can be set to one. The maximum width of the corresponding grain pattern W can be a variable based on the overall image resolution. For example, when the overall image resolution is less than or equal to 1920x1080, W can be set to 8; when the overall image resolution is 1920x1080 and up to 3840x2160 (4K), W can be set to 16; and when the overall image resolution is greater than 4K (including (or up to) 8K), W can be set to 32. In this case, for image resolutions less than 1920x1080, the film grain composite block size can be set to 1x8; for overall image resolutions greater than 1920x1080 and up to 3840x2160 (4K), the film grain composite block size can be set to 1x16; and for overall image resolutions greater than 4K, including (or up to) 8K, the film grain composite block size can be set to 1x32. In some cases, the value of W can be the same as the width of the current block. In step 402 of program 400, a database of particle patterns can be obtained, which can have different combinations of horizontal and vertical cutoff frequencies. In step 404, if an additional row (e.g., a row of primitives) exists in the current block, execution proceeds to step 406. For example, an 8x8 current block may include eight rows of eight primitives. At step 406, a 1xW block (e.g., a row) from the current block is obtained and stored in memory. In some cases, this memory may be part of a row in a row buffer. In other cases, since the size of the 1xW block is relatively small, the block may be stored in non-row buffer memory. Avoiding the use of a row buffer for film grain synthesis can help reduce or even eliminate the row buffer, potentially reducing hardware costs. At step 408, an average brightness value can be determined for the 1xW block. This average brightness value for a row can be stored in memory. Execution can then return to step 404. Each row in the current block can be traversed to obtain and store the average brightness value for each row of the current block. The average brightness value of the rows in the current block can be stored in any memory. Execution can then proceed to step 410. At step 410, the overall average brightness value of the current block can be determined based on the average brightness value of each row of the current block. For example, the overall average brightness value can be determined by averaging the average brightness values of each row of the current block. At step 412, the intensity level can be determined by comparing the overall average brightness value with the upper and lower limits of the intensity range transmitted in the FGC SEI message. At step 414, a particle pattern is selected from the particle pattern database based on the cutoff frequency indicated by the comparison between the average brightness value and the intensity range boundaries. At step 416, a level offset and a vertical offset are selected. In some cases, the horizontal and vertical offsets can be selected via a pseudo-random procedure. In some instances, the horizontal offset used to select the grain pattern block can be set to 0 when the width of the grain composite block is equal to the width of the grain pattern. For example, when the grain pattern width is less than the width of the grain composite block, a random horizontal offset can be used to place the film grains into the grain composite block during video decoding, while avoiding patterns that viewers might notice for the film grains. However, if the grain pattern has the same width as the grain composite block, a horizontal offset may not be applied. At step 418, particle blocks are selected from the particle pattern based on the horizontal and vertical offsets from the selected particle pattern. In some cases, particle blocks are selected to be applied to the current block, and this can be done based on the first row of primitives in the current block. At step 420, the selected grain block is adjusted based on the grain intensity indicated for the corresponding intensity range, and the edges of the vertical grain block are deblocked. At step 422, the adjusted sampled values (e.g., the adjusted grain block) are added to the decoded current block to produce an output image that includes synthetic film grain. As another example, for overall image resolutions greater than 1920x1080 and up to 3840x2160 (4K), the film grain composite size can be set to 8x16; and for overall image resolutions greater than 4K, including (or up to) 8K, the film grain composite size can be set to 8x32. In addition or alternatively, in some cases, these systems and techniques can provide improvements to the film grain database. According to such cases, the current 169 64x64 grain patterns can be reduced to save hardware implementation storage, since the database is typically pre-computed and stored in memory. In one instance, a method for reducing the cutoff frequency is provided, in which case the number of cutoff frequencies can be reduced from 13 to 7 (e.g., 7 horizontal cutoff frequencies and 7 vertical cutoff frequencies), which reduces the grain database size to 49 64x64 grain patterns and reduces the storage capacity to approximately 20KB. According to such cases, the derivation of variables fgCutFreqH[h], fgCutFreqV[v], and fgCoeffs[h][v][i][j], as proposed in JVET-W0095, is modified as follows (the changes are expressed in words such as "fgCutFreqH[h]", "fgCutFreqV[v]", and "fgCoeffs[h][v][i][j]"). (Bold, italic, and underlined text shown): The variable fgCutFreqH[h] is set to equal to ((h + 2) << 3) – 5, where h = 0. 6. The variable fgCutFreqV[v] is set to equal to ((v + ... 2) << 3) – 5, where v = 0. 6. The variable fgCoeffs[h][v][i][j] is initially set to 0, where h = 0. 6, v = 0. 6, i = 0..63, j = 0..63, and is derived as follows: for(h = 0; h < 7 , h++ ) { for(v = 0; v < 7 , v++ ) { prngVal = SeedLUT( 2 * h + 26 * v ) for( j = 0; j <= fgCutFreqV[ v ] ; j++ ) { for( i = 0; i <= fgCutFreqH[ h ] ; i + = 8) { for( k = 0; k < 0;} 8 ; k++ ) fgCoeffs[ h ][ v ][ i + k ][ j ] = gaussianLUT[ ( prngVal + k ) % 2048 ] prngVal = Prng( prngVal )}} fgCoeffs[ h ][ v ][ 0 ][ 0 ] = 0}} SMPTE RDD 5 specifies that the values of the FGC SEI message syntax elements comp_model_value[c][i][1] and comp_model_value[c][i][2] are based on 13 horizontal cutoff frequencies and the vertical cutoff frequency should be in the range of 2 to 14. According to the pattern described herein, the particle mixing procedure can be modified as follows to accommodate a reduced number of cutoff frequencies (the variation is based on...). (Bold, italic, and underlined text shown): The variable intensityIntevalIdx used for the current block is initialized to -1 and is derived as follows: sumBlock = 0 avgRatio = Log2( BlockSize / 8) for( i = 0; i < BlockSize ; i++ ) for( j = 0; j < BlockSize ; j++ ) sumBlock += decSamples[ Min( picWidth − 1, xCurr + i ) ][ Min( picHeight − 1, yCurr + j ) ] (xx) b avg = Clip3( 0, 255, ( sumBlock + ( 1 << ( fgBitDepth[ cIdx ] + 2 * avgRatio − 3 ) ) ) >> ( fgBitDepth[ cIdx ] + 2 * avgRatio − 2 ) for( i = 0; i <= fg_num_intensity_intervals_minus1[ cIdx ]; i++ ) if( b avg >= fg_intensity_interval_lower_bound[ cIdx ][ i ] && b avg<= fg_intensity_interval_upper_bound[ cIdx ][ i ] ) { intensityIntervalIdx = i >> 1 (xx) break} In another example, a method is provided to reduce the particle pattern size from 64x64 to 32x32, resulting in a particle database size of 169 32x32 particles with the same cutoff frequency, and a storage capacity of approximately 17KB. In this example, the derivation of variables fgCutFreqH[h], fgCutFreqV[v], and fgCoeffs[h][v][i][j], as proposed in JVET-W0095, is modified as follows (the changes are expressed in words). (Bold, italic, and underlined text indicates): The variable fgCutFreqH[h] is set to equal to ((h + 3) << 1) – 1, where h = 0..12. The variable fgCutFreqV[v] is set to equal to ((v + 3) << 1) – 1, where v = 0..12. The variable fgCoeffs[ h ][ v ][ i ][ j ] is initially set to 0, where h = 0..12, v = 0..12, i = 0.. 31, j = 0. 31, and is derived as follows: for(h = 0; h < 13, h++) { for(v = 0; v < 13, v++) { prngVal = SeedLUT(h + 13 * v) for(j = 0; j <= fgCutFreqV[v]; j++) { for(i = 0; i <= fgCutFreqH[h]; i += 2) { for( k = 0; k < 0;} 2 ; k++ ) fgCoeffs[ h ][ v ][ i + k ][ j ] = gaussianLUT[ ( prngVal + k ) % 2048 ] prngVal = Prng( prngVal )}} fgCoeffs[ h ][ v ][ 0 ][ 0 ] = 0}} In some cases, the size of the particle pattern database can be reduced by decreasing the particle pattern size from 64x64 to 32x32 and the number of cutoff frequencies from 13 to 7. The total storage space is reduced to 5KB. In such cases, the derivation of variables fgCutFreqH[h], fgCutFreqV[v], and fgCoeffs[h][v][i][j], as proposed in JVET-W0095, is modified as follows (the changes are expressed in words). (Bold, italic, and underlined text indicates): The variable fgCutFreqH[h] is set to equal to ((h + 1) << 2) – 1, where h = 0..6. The variable fgCutFreqV[v] is set to equal to ((v + 1) << 2) – 1, where v = 0..6. The variable fgCoeffs[h][v][i][j] is initially set to equal to 0, where h = 0..6, v = 0..6, i = 0..31, j = 0..31, and is derived as follows: for(h = 0; h < 13, h++) { for(v = 0; v < 13, v++) { prngVal = SeedLUT(2 * h + 26 * v) for(j = 0; j <= fgCutFreqV[ v ] ; j++ ) { for( i = 0; i <= fgCutFreqH[ h ] ; i + = 4 ) { for( k = 0; k < 4; k++ ) fgCoeffs[ h ][ v ][ i + k ][ j ] = gaussianLUT[ ( prngVal + k ) % 2048 ] prngVal = Prng( prngVal )}} fgCoeffs[ h ][ v ][ 0 ][ 0 ] = 0}} In some instances, when the grain pattern size is reduced to 32x32, the corresponding maximum width of the film grain composite block is 32. In addition or alternatively, in some cases, these systems and techniques can provide texture pattern database generation. The particle pattern database generation proposed in JVET-W0095 does not cover all frequencies because the variable fgCoeffs
[12]
[12] [i][j] is only filled with a 59x59 pseudo-random number. According to one example, the derivation provided in JVET-W0095 is modified as follows to cover all frequencies (the variation is given by...). (Bold, italic, and underlined text is shown). The variable fgCutFreqH[h] is set to equal to ((h + ... 4) << 2) – 1, where h = 0..12. The variable fgCutFreqV[v] is set to equal to ((v + 4) << 2) – 1, where v = 0..12. The variable fgCoeffs[h][v][i][j] is initially set to 0, where h = 0..12, v = 0..12, i = 0..63, j = 0..63, and is derived as follows: for(h = 0; h < 13, h++) { for(v = 0; v < 13, v++) { prngVal = SeedLUT(h + 13 * v) for(j = 0; j <= fgCutFreqV[v]; j++) { for(i = 0; i <= fgCutFreqH[h]; i += 4) { for(k = 0; k < 4; k++) fgCoeffs[h][v] ][ i + k ][ j ] = gaussianLUT[ ( prngVal + k ) % 2048 ] prngVal = Prng( prngVal )}} fgCoeffs[ h ][ v ][ 0 ][ 0 ] = 0}} Supplementally or alternatively, in some forms, these systems and techniques may provide one or more methods to perform (and in some cases enforce) film grain composition. In some forms, syntax elements (which may be referred to as film grain application syntax elements) may be added to parameter sets, such as Sequence Parameter Set (SPS), Picture Parameter Set (PPS), picture headers, or other fields or parameter sets. In some cases, the proposed syntax elements require the presence of an FGC SEI message. Supplementally or alternatively, in some cases, the proposed syntax elements require the application of film grain composition to an associated decoded video sequence or picture. For example, the proposed syntax elements may require the presence of an FGC SEI message and also require the application of film grain composition to an associated decoded video sequence or picture. In some illustrative examples, for existing video transcoders such as VVC or other existing transcoders, the relevant film grain application syntax element can be added to the reserved extension field. An illustrative example is adding a film grain application syntax element to the SPS extension field as shown below, which can be represented as `sps_fg_apply_flag` (varies by...). (Bold, italic, and underlined text shown) An illustrative example of the semantics of the new `sps_film_grain_apply_flag` syntax element is as follows: `sps_film_grain_apply_flag` equal to 1 specifies that at least one FGC SEI message should be present in the associated bitstream, and film grain composition should be applied to the associated CLVS. `sps_film_grain_apply_flag` equal to 0 does not impose such a constraint. In some explanatory formats, the film grain application syntax element can be added to the Video Usability Information (VUI) Payload Extension field as follows (the variation is as follows). (Bold, italic, and underlined text shown) An illustrative example of the semantics of the new `vui_film_grain_apply_flag` syntax element is as follows: `vui_film_grain_apply_flag` equal to 1 specifies that at least one FGC SEI message should be present in the associated bitstream, and film grain composition should be applied to the associated CLVS. `vui_film_grain_apply_flag` equal to 0 does not impose such a constraint. Supplementally or alternatively, in some cases, these systems and technologies can provide film grain constraint indicators. As mentioned above, in some situations, indicators of film grain relay data availability will benefit decoder parsing procedures (e.g., when film grain relay data is included in one or more SEI messages, among one or more users registered by a recommended ITU-T T.35 SEI message with a specific ITU-T T.35 code, and / or other cases). Film grain constraint indicators can indicate the availability of film grain relay data in an associated bitstream. In some cases, the indicator can be signaled in one or more syntax elements or structures (e.g., in the general constraint information syntax, such as the general_constraints_info() syntax for VVC or other transcoders or video decoding standards or formats) or in one or more parameters (e.g., in the Video Availability Information (VUI) parameter). An illustrative example of the VUI film grain indicator is provided in the film grain constraint syntax elements below and is represented as vui_non_film_grain_constraint_flag (varies by...). (Bold, italic, and underlined text shown) An illustrative example of the semantics of the new `vui_non_film_grain_constraint_flag` syntax element is as follows: `vui_non_film_grain_constraint_flag` equal to 1 specifies that no film grain characteristic SEI information should exist, or any user data registered by the recommended ITU-T T.35 SEI message carrying film grain relay data applicable to CLVS. `vui_non_film_grain_constraint_flag` equal to 0 does not impose such a constraint. Figure 5 is a flowchart illustrating an example of a program 500 for processing video data according to the present invention. Program 500 may be executed by a computing device (or apparatus) or a component of a computing device (e.g., a chipset, transcoder, etc.). The computing device may be a mobile device (e.g., a mobile phone), a network-connected wearable device (e.g., a watch), an extended reality (XR) device (e.g., a virtual reality (VR) device or an augmented reality (AR) device), a vehicle or a component or system of a vehicle, or other types of computing devices. In some cases, the computing device may be or may include a decoding device, such as an encoding device 104, a decoding device 112, or a combined encoding device (or transcoder). The operation of program 500 may be implemented as a software component that executes and runs on one or more processors. At step 502, the computing device (or its components) can acquire video data including the image. At step 504, the computing device (or its components) can determine the width of the film grain composite block of the image based on at least one of the width and height of the image. In some cases, the width value of the film grain composite block is in the range of 8 to W, including 8 and W, where W is the maximum width of the corresponding grain pattern. In some cases, the computing device (or its components) can determine at least one of the width and height of the film grain composite block of the image based on at least one of the width and height of the image, and the computing device (or its components) can determine the width of the film grain composite block of the image based on the width and height of the image. At step 506, the computing device (or a component thereof) may determine that the height of the film grain composite block of the image is one. At step 508, the computing device (or a component thereof) may determine the block size of the film grain composite block based on the determined width and height. At step 510, the computing device (or its components) may select a particle block based on the determined block size. In some cases, the computing device (or its components) may obtain a current sample block from an image; obtain a set of primitives from the current sample block based on the determined block size; and determine an average brightness value for the set of primitives, wherein the computing device (or its components) may select a particle block based on the average brightness value in order to select a particle block. In some cases, the set of primitives includes a row of primitives from the current sample block, and the computing device (or its components) may determine an average brightness value for each row of primitives in the current sample block; determine an overall average brightness value for the current sample block based on the average brightness value for each row of primitives; and determine an intensity level based on the overall average brightness value. In some cases, the computing device (or its components) may select a particle pattern based on this intensity level; and randomly select at least a vertical offset, wherein a particle block is selected based on the vertical offset from the particle pattern in order to select a particle block. In some cases, the computing device (or its components) may decode the current sample block; add the selected grain block to the decoded current sample block to produce an output current block; and output the output current block. In some cases, the computing device (or its components) may determine that the width of the film grain composite block is equal to the width of the corresponding grain pattern; and set the horizontal offset used to select the grain pattern block to 0. The programs (or methods) described herein can be used alone or in any combination. In some embodiments, the programs (or methods) described herein can be executed by a computing device or apparatus (e.g., system 100 shown in FIG. 1). For example, these programs can be executed by the encoding device 104 shown in FIG. 1 and FIG. 6, by another video source-side device or video transmission device, by the decoding device 112 shown in FIG. 1 and FIG. 7, and / or by another client device (e.g., a player device, a display, or any other client device). In some cases, the computing device or apparatus may include one or more input devices, one or more output devices, one or more processors, one or more microprocessors, one or more microcomputers, and / or other components configured to perform the steps of one or more programs described herein. In some instances, a computing device may include a mobile device, a desktop computer, a server computer and / or a server system, or other types of computing devices. Components of the computing device (e.g., one or more input devices, one or more output devices, one or more processors, one or more microprocessors, one or more microcomputers, and / or other components) may be implemented in circuitry. For example, components may include electronic circuitry or other electronic hardware and / or may be implemented therein, such electronic circuitry or other electronic hardware may include one or more programmable electronic circuits (e.g., microprocessors, graphics processing units (GPUs), digital signal processors (DSPs), central processing units (CPUs), and / or other suitable electronic circuitry), and / or may include computer software, firmware, or any combination thereof and / or may be implemented therein to perform the various operations described herein. In some instances, a computing device or apparatus may include a camera configured to capture video data (e.g., a video sequence) including video frames. In some instances, the camera or other capturing device for capturing video data is separate from the computing device, in which case the computing device receives or acquires the captured video data. Computing devices may include a network interface configured to transmit video data. The network interface may be configured to transmit Internet Protocol (IP) based data or other types of data. In some instances, the computing device or apparatus may include a display for displaying output video content (e.g., samples of images from a video bitstream). Programs can be described using logic flowcharts, whose actions represent a series of operations that can be implemented using hardware, computer instructions, or a combination thereof. In the context of computer instructions, actions represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a specific function or implement a specific data type. The order in which operations are described should not be construed as restrictive, and any number of described operations can be combined in any order and / or in parallel to implement a program. Furthermore, the program can be executed under the control of one or more computer systems configured with executable instructions, and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that can be executed jointly on one or more processors via hardware or a combination thereof. As mentioned above, the code can be stored, for example, on a computer-readable or machine-readable storage medium in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable or machine-readable storage medium can be non-transitory. The decoding techniques discussed in this paper can be implemented in an example video encoding and decoding system (e.g., System 100). In some instances, the system includes a source device that provides encoded video data for later decoding by a destination device. Specifically, the source device provides video data to the destination device via computer-readable media. The source and destination devices can include any of a variety of devices, including desktop computers, laptops, tablets, set-top boxes, handheld telephone devices (e.g., so-called "smart" phones, so-called "smart" tablets), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, and so on. In some cases, the source and destination devices can be configured for wireless communication. A destination device can receive encoded video data to be decoded via computer-readable media. Computer-readable media can include any type of media or device capable of moving encoded video data from a source device to a destination device. In one example, computer-readable media can include communication media that enables the source device to send encoded video data directly and instantly to the destination device. The encoded video data can be modulated according to communication standards (e.g., wireless communication protocols) and sent to the destination device. Communication media can include any wireless or wired communication media, such as radio frequency (RF) spectrum or one or more physical transmission lines. Communication media can form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. Communication media can include routers, switches, base stations, or any other device that facilitates communication from the source device to the destination device. In some instances, encoded data can be output from an output interface to a storage device. Similarly, encoded data can be accessed from a storage device via an input interface. The storage device can include any of a variety of distributed or locally accessed data storage media, such as hard drives, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory, or any other suitable digital storage media for storing encoded video data. In another instance, the storage device can correspond to a file server or another intermediate storage device capable of storing encoded video generated by a source device. The destination device can access the stored video data from the storage device via data streaming or downloading. The file server can be any type of server capable of storing encoded video data and sending it to the destination device. Examples of file servers include network servers (e.g., for websites), FTP servers, Network Additional Storage (NAS) devices, or local disk drives. The destination device can access the encoded video data via any standard data connection, including an Internet connection. This can include a wireless channel (e.g., Wi-Fi connection), a wired connection (e.g., DSL, cable modem, etc.), or a combination of both, suitable for accessing encoded video data stored on a file server. Transmission of the encoded video data from the storage device can be a data stream, a download transfer, or a combination thereof. The technologies described in this case are not limited to wireless applications or setups. These technologies can be applied to video decoding that supports any of a variety of multimedia applications, such as over-the-air television broadcasting, cable television transmission, satellite television transmission, internet streaming video transmission, such as Dynamic Self-Adjusting Data Streaming (DASH) over HTTP, digital video encoded onto data storage media, decoding digital video stored on data storage media, or other applications. In some instances, the system can be configured to support one-way or two-way video transmission to support applications such as video data streaming, video replay, video broadcasting, and / or video telephony. In one example, the source device includes a video source, a video transcoder, and an output interface. The destination device may include an input interface, a video decoder, and a display device. The video transcoder of the source device may be configured to apply the techniques disclosed herein. In other examples, the source and destination devices may include other components or arrangements. For example, the source device may receive video data from an external video source such as an external camera. Similarly, the destination device may interface with an external display device, rather than including an integrated display device. The example system described above is merely one example. Techniques for processing video data in parallel can be implemented via any digital video encoding and / or decoding device. While the techniques described herein are generally implemented by video encoding devices, they can also be implemented by video transcoders / decoders commonly referred to as "CODECs." Furthermore, the techniques described herein can also be implemented by video preprocessors. The source and destination devices are merely examples of such decoding devices, where the source device generates decoded video data for transmission to the destination device. In some instances, the source and destination devices can operate in a substantially symmetrical manner, such that each of these devices includes video encoding and decoding components. Therefore, the example system can support one-way or two-way video transmission between video devices, for example, for video streaming, video replay, video broadcasting, or video telephony. A video source may include a video capturing device (e.g., a camera, a video file containing previously captured video, and / or a video feed interface) to receive video from a video content provider. Alternatively, the video source may generate computer-graphics-based data as source video, or a combination of live video, archived video, and computer-generated video. In some cases, if the video source is a video camera, the source and destination devices may form a so-called camera phone or video phone. However, as mentioned above, the techniques described in this application are generally applicable to video decoding and can be used in wireless and / or wired applications. In each case, captured, pre-captured, or computer-generated video may be encoded by a video transcoder. The encoded video information can then be output to a computer-readable medium via an output interface. As mentioned above, computer-readable media can include transient media (such as wireless broadcasting or wired network transmission), or storage media (i.e., non-transitory storage media) (such as hard disks, flash memory drives, optical discs, digital video discs, Blu-ray discs), or other computer-readable media. In some instances, a network server (not shown) can receive encoded video data from a source device, for example, via a network transmission, and provide the encoded video data to a destination device. Similarly, a media production facility (such as a disc stamping facility) or computing device can receive encoded video data from a source device and produce a disc containing the encoded video data. Therefore, in various instances, computer-readable media can be understood to include one or more forms of computer-readable media. The input interface of the destination device receives information from computer-readable media. The information in the computer-readable media may include syntax information defined by a video transcoder, which is also used by the video decoder. This syntax information includes characteristics of description blocks and other decoding units (e.g., groups of pictures (GOPs)) and / or processed syntax elements. A display device displays the decoded video data to the user and may include any of a variety of display devices, such as a cathode ray tube (CRT), liquid crystal display (LCD), plasma display, organic light-emitting diode (OLED) display, or another type of display device. Various embodiments of this invention have been described. Figures 6 and 7 illustrate specific details of the encoding device 104 and the decoding device 112, respectively. Figure 6 is a block diagram illustrating an example encoding device 104 that can implement one or more of the techniques described herein. The encoding device 104 can, for example, generate the syntax elements and / or structures described herein (e.g., syntax elements and / or structures of green relay data, such as complexity indices (CM), or other syntax elements and / or structures). The encoding device 104 can perform intra-prediction and inter-prediction decoding on video blocks within video slices, tiles, sub-pictures, etc. As mentioned above, intra-decoding relies at least in part on spatial prediction to reduce or remove spatial redundancy within a given video frame or picture. Inter-decoding relies at least in part on temporal prediction to reduce or remove temporal redundancy within adjacent or surrounding frames of a video sequence. Intra-mode (I-mode) can refer to any of several spatial-based compression modes. Inter-mode (e.g., one-way prediction (P-mode) or two-way prediction (B-mode)) can refer to any of several time-based compression modes. Encoding device 104 includes a partitioning unit 35, a prediction processing unit 41, a filter unit 63, an image memory 64, a summer 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. Prediction processing unit 41 includes a motion estimation unit 42, a motion compensation unit 44, and an intra-prediction processing unit 46. For video block reconstruction, encoding device 104 also includes an inverse quantization unit 58, an inverse transform processing unit 60, and a summer 62. Filter unit 63 is intended to represent one or more loop filters, such as a deblocking filter, an ALF (Alternating Loop Filter), and a Sample-Alternating Offset (SAO) filter. Although filter unit 63 is shown as a loop filter in FIG. 6, in other configurations, filter unit 63 can be implemented as a post-loop filter. Post-processing device 57 can perform additional processing on the encoded video data generated by encoding device 104. In some cases, the techniques of this invention can be implemented by encoding device 104. However, in other cases, one or more techniques of this invention can be implemented by post-processing device 57. As shown in Figure 6, the encoding device 104 receives video data, and the partitioning unit 35 partitions the data into video blocks. Partitioning may also include, for example, partitioning into slices, slice fragments, tiles, or other larger units based on the quadtree structure of LCUs and CUs, as well as video block partitioning. The encoding device 104 is typically illustrated as a component that encodes video blocks within a video slice to be encoded. A slice may be partitioned into multiple video blocks (and may be partitioned into a set of video blocks referred to as tiles). The prediction processing unit 41 may select one of several possible decoding modes for the current video block based on error results (e.g., decoding rate and distortion level, etc.), such as one of several intra-prediction decoding modes or one of several inter-prediction decoding modes. The prediction processing unit 41 may provide the resulting intra-decoded block or inter-decoded block to the summer 50 to generate residual block data, and provide it to the summer 62 to reconstruct the encoded block for use as a reference image. The intra-prediction processing unit 46 within the prediction processing unit 41 can perform intra-prediction decoding of the current video block relative to one or more adjacent blocks in the same frame or slice as the current block to be decoded, to provide spatial compression. The motion estimation unit 42 and motion compensation unit 44 within the prediction processing unit 41 perform inter-prediction decoding of the current video block relative to one or more prediction blocks in one or more reference images, to provide temporal compression. Motion estimation unit 42 can be configured to determine the inter-prediction mode of video slices based on a predetermined mode of the video sequence. The predetermined mode can designate video slices in the sequence as P-slices, B-slices, or GPB-slices. Motion estimation unit 42 and motion compensation unit 44 can be highly integrated, but are shown separately for conceptual purposes. Motion estimation performed by motion estimation unit 42 is a procedure that generates motion vectors that estimate the motion of video blocks. The motion vectors can, for example, indicate the displacement of a prediction unit (PU) of a video block within the current video frame or image relative to a prediction block within a reference image. The predicted block is a block whose primitive difference closely matches the PU of the video block to be decoded, found based on primitive differences. Primitive differences can be determined by the sum of absolute differences (SAD), the sum of squared differences (SSD), or other difference metrics. In some instances, the encoding device 104 can calculate the values of sub-integer primitive positions of a reference image stored in the image memory 64. For example, the encoding device 104 can interpolate the values of quarter-priority, eighth-priority, or other fractional primitive positions of the reference image. Therefore, the motion estimation unit 42 can perform motion search relative to all primitive positions and fractional primitive positions, and output a motion vector with fractional primitive precision. The motion estimation unit 42 calculates the motion vector of the PU in the video block within the inter-decoded slice by comparing the position of the PU with the position of the predicted block of the reference image. Reference images 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 64. The motion estimation unit 42 sends the calculated motion vector to the entropy coding unit 56 and the motion compensation unit 44. Motion compensation performed by motion compensation unit 44 may involve obtaining or generating prediction blocks based on motion vectors determined by motion estimation, possibly performing interpolation on sub-primitive accuracy. Upon receiving the motion vector of the PU for the current video block, motion compensation unit 44 can locate the prediction block to which the motion vector points in a list of reference images. Encoding device 104 forms a residual video block by subtracting the primitive values of the prediction block from the primitive values of the current video block being decoded, thereby forming a primitive difference. The primitive difference forms the residual data of the block and may include both luminance difference components and chrominance difference components. Summer 50 represents the component or components that perform the subtraction operation. Motion compensation unit 44 may also generate syntax elements associated with video blocks and video slices for use by decoding device 112 in decoding video blocks of video slices. As previously mentioned, the intraprediction processing unit 46 can perform intraprediction on the current block as an alternative to the interprediction performed by the motion estimation unit 42 and the motion compensation unit 44. Specifically, the intraprediction processing unit 46 can determine the intraprediction mode used to encode the current block. In some instances, the intraprediction processing unit 46 can encode the current block using various intraprediction modes (e.g., in a separate encoding procedure), and the intraprediction processing unit 46 can select a suitable intraprediction mode from the tested modes. For example, the intraprediction processing unit 46 can use rate-distortion analysis to calculate rate-distortion values for various tested intraprediction modes, and can select the intraprediction mode with the best rate-distortion characteristics from the tested modes. Rate-distortion analysis typically determines the amount of distortion (or error) between the coded block and the original, uncoded block that was encoded to produce the coded block, as well as the bit rate (i.e., number of bits) used to generate the coded block. The intraprediction processing unit 46 can calculate a ratio based on the distortion and rate of various coded blocks to determine which intraprediction mode exhibits the best rate-distortion value for the block. In any case, after selecting an intraprediction mode for a block, the intraprediction processing unit 46 can provide information indicating the selected intraprediction mode for that block to the entropy coding unit 56. The entropy coding unit 56 can encode the information indicating the selected intraprediction mode. The encoding device 104 can include data definitions for encoding contexts for various blocks in the transmitted bitstream configuration, as well as an indication of the most likely intraprediction mode, an intraprediction mode index table, and a modified intraprediction mode index table for each context. The bitstream configuration data can include a plurality of intraprediction mode index tables and a plurality of modified intraprediction mode index tables (also referred to as codeword mapping tables). After prediction processing unit 41 generates a prediction block for the current video block via inter-prediction or intra-prediction, encoding device 104 forms a residual video block by subtracting the prediction block from the current video block. The residual video data in the residual block can be included in one or more TUs and is applied to transform processing unit 52. Transform processing unit 52 uses a transform (e.g., discrete cosine transform (DCT) or a conceptually similar transform) to transform the residual video data into residual transform coefficients. Transform processing unit 52 can transform the residual video data from the primitive domain to the transform domain, such as the frequency domain. The transform processing unit 52 can send the resulting transform coefficients to the quantization unit 54. The quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization procedure can reduce the bit depth associated with some or all of the coefficients. The degree of quantization can be modified by adjusting the quantization parameters. In some instances, the quantization unit 54 can then perform a scan of the matrix including the quantized transform coefficients. Alternatively, the entropy coding unit 56 can perform the scan. After quantization, entropy coding unit 56 performs entropy coding on the quantized transform coefficients. For example, entropy coding unit 56 can perform context-adjusted variable-length decoding (CAVLC), context-adjusted binary arithmetic decoding (CABAC), syntax-based context-adjusted binary arithmetic decoding (SBAC), probability interval partitioning entropy (PIPE) decoding, or other entropy coding techniques. After entropy coding by entropy coding unit 56, the encoded bitstream can be sent to decoding device 112, or archived for later transmission or retrieval by decoding device 112. Entropy coding unit 56 can also perform entropy coding on the motion vectors and other syntax elements of the currently decoded video slice. Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct residual blocks in the primitive domain for later use as reference blocks in reference images. Motion compensation unit 44 can compute reference blocks by adding the residual blocks to a prediction block of one of the reference images in the reference image list. Motion compensation unit 44 can also apply one or more interpolation filters to the reconstructed residual blocks to compute sub-integer primitive values for motion estimation. Summer 62 adds the reconstructed residual blocks to the motion-compensated prediction blocks generated by motion compensation unit 44 to generate reference blocks for storage in image memory 64. The reference blocks can be used by motion estimation unit 42 and motion compensation unit 44 for inter-block prediction in subsequent video frames or images. In this way, the encoding device 104 of Figure 6 represents an instance of a video transcoder configured to perform any of the techniques described herein. In some cases, some of the techniques described herein may also be implemented by the post-processing device 57. Figure 7 is a block diagram illustrating an example decoding device 112. Decoding device 112 includes an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, a summer 90, a filter unit 91, and an image memory 92. The prediction processing unit 81 includes a motion compensation unit 82 and an intra-prediction processing unit 84. In some instances, decoding device 112 can perform a decoding pass that is generally the inverse of the encoding procedure described for encoding device 104 of Figure 6. During the decoding process, decoding device 112 receives an encoded video bitstream representing video blocks of encoded video slices and associated syntax elements sent by encoding device 104. In some embodiments, decoding device 112 may receive the encoded video bitstream from encoding device 104. In some embodiments, decoding device 112 may receive the encoded video bitstream from network entity 79 (e.g., a server, a media-aware network component (MANE), a video editor / splitter, or other such device configured to implement one or more of the technologies described above). Network entity 79 may or may not include encoding device 104. Some of the technologies described herein may be implemented by network entity 79 before it sends the encoded video bitstream to decoding device 112. In some video decoding systems, network entity 79 and decoding device 112 may be parts of separate devices, while in other cases, the functionality described for network entity 79 may be performed by the same device including decoding device 112. The entropy decoding unit 80 of the decoding device 112 performs entropy decoding on the bitstream to generate quantization coefficients, motion vectors, and other syntax elements. The entropy decoding unit 80 forwards the motion vectors and other syntax elements to the prediction processing unit 81. The decoding device 112 can receive syntax elements at the video slice level and / or the video block level. The entropy decoding unit 80 can process and parse both fixed-length and variable-length syntax elements from one or more parameter sets (e.g., VPS, SPS, and PPS). When a video slice is decoded into an intra-decoded (I) slice, the intra-prediction processing unit 84 of the prediction processing unit 81 can generate prediction data for video blocks of the current video slice based on the intra-prediction mode transmitted by the signal and previously decoded blocks from the current frame or picture. When a video frame is decoded into an inter-decoded (i.e., B, P, or GPB) slice, the motion compensation unit 82 of the prediction processing unit 81 generates prediction blocks for video blocks of the current video slice based on motion vectors and other syntax elements received from the entropy decoding unit 80. Prediction blocks can be generated from one of the reference pictures in the reference picture list. The decoding device 112 can construct the reference frame list, list 0, and list 1 based on the reference pictures stored in the picture memory 92 using a preset construction technique. The motion compensation unit 82 determines prediction information for video blocks in the current video slice by parsing motion vectors and other syntax elements, and uses this prediction information to generate prediction blocks for the currently decoded video block. For example, the motion compensation unit 82 may use one or more syntax elements in the parameter set to determine the prediction mode (e.g., intra-prediction or inter-prediction), the inter-prediction slice type (e.g., B-slice, P-slice, or GPB-slice), the construction information of one or more reference picture lists for the slice, the motion vectors of each inter-coded video block in the slice, the inter-prediction state of each inter-decoded video block in the slice, and other information for decoding video blocks in the current video slice. The motion compensation unit 82 can also perform interpolation based on an interpolation filter. The motion compensation unit 82 can use the interpolation filter used by the encoding device 104 during the encoding of the video block to calculate the interpolated values of the sub-integer primitives of the reference block. In this case, the motion compensation unit 82 can determine the interpolation filter used by the encoding device 104 from the received syntax elements, and can use the interpolation filter to generate the prediction block. The inverse quantization unit 86 inverse-quantizes or dequantizes the quantized transform coefficients provided in the bitstream and decoded by the entropy decoding unit 80. The inverse quantization procedure may include determining the quantization level using quantization parameters calculated by the encoding device 104 for each video block of the video slice, and similarly determining the inverse quantization level to be applied. The inverse transform processing unit 88 applies an inverse transform (e.g., inverse DCT or other suitable inverse transform), an inverse integer transform, or a conceptually similar inverse transform procedure to the transform coefficients to generate residual blocks in the primitive domain. After the motion compensation unit 82 generates a prediction block for the current video block based on motion vectors and other syntax elements, the decoding device 112 forms a decoded video block by adding the residual block from the inverse transform processing unit 88 to the corresponding prediction block generated by the motion compensation unit 82. Adder 90 represents one or more components performing this summation operation. If needed, loop filters (in or after the decoding loop) can also be used to smooth primitive transitions or otherwise improve video quality. Filter unit 91 is intended to represent one or more loop filters, such as a deblocking filter, an ALF (Alternating Alignment Loop Filter), and a Sampling Self-Adjusting Offset (SAO) filter. Although filter unit 91 is shown as a loop filter in FIG. 7, in other configurations, filter unit 91 can be implemented as a post-loop filter. The decoded video block in a given frame or picture is then stored in picture memory 92, which stores a reference picture for subsequent motion compensation. Image memory 92 also stores decoded video for later display on a display device, such as video destination device 122 shown in Figure 1. In this way, the decoding device 112 of Figure 7 represents an instance of a video decoder configured to perform any of the techniques described herein. As used herein, the term "computer-readable media" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instructions and / or data. Computer-readable media may include media in which data can be stored, but excludes non-transitory media that transmit wirelessly or via a wired connection, carrying carrier waves and / or transient electronic signals. Examples of non-transitory media may include, but are not limited to, magnetic disks or magnetic tapes, optical storage media such as optical discs (CDs) or digital versatile discs (DVDs), flash memory, memory, or storage devices. Computer-readable media may store code and / or machine-executable instructions that may represent programs, functions, subroutines, programs, routines, modules, software packages, software components, or any combination of instructions, data structures, or program statements. Code segments may be coupled to another code segment or hardware circuitry by transmitting and / or receiving information, data, arguments, parameters, or memory contents. Information, parameters, and other data can be transmitted, forwarded, or sent through any suitable means, including memory sharing, message passing, symbol passing, and network transmission. In some embodiments, computer-readable storage devices, media, and memory may include cable or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and the signals themselves. Specific details have been provided in the foregoing description to provide a thorough understanding of the embodiments and examples presented herein. However, it will be understood by those skilled in the art to which this invention pertains that these embodiments may be practiced without using these specific details. For clarity, in some instances, the technology may be presented as comprising individual functional blocks, which include devices, device components, steps or routines in a method embodied in software, or a combination of hardware and software. Other components may be used in addition to those shown in the figures and / or described herein. For example, circuits, systems, networks, programs, and other components may be shown as components in block diagram form to avoid obscuring the embodiments with unnecessary details. For example, well-known circuits, programs, algorithms, structures, and techniques may be shown without unnecessary details to avoid obscuring the embodiments. Various embodiments can be described as programs or methods, illustrated as flowcharts, data flow diagrams, structural diagrams, or block diagrams. Although a flowchart can describe operations as a sequential procedure, many operations within an operation can be executed in parallel or concurrently. Furthermore, the order of these operations can be rearranged. A program terminates upon completion of its operations, but the program may have additional steps not shown in the diagram. A program can correspond to a method, function, procedure, subroutine, subroutine, etc. When a program corresponds to a function, its termination can correspond to the function returning to the calling function or the main function. The programs and methods according to the examples described above can be implemented using computer-executable instructions stored in or available from a computer-executable medium. For example, such instructions may include instructions and data that cause a general-purpose computer, special-purpose computer, or processing device to perform a function or group of functions, or otherwise configure such a computer, special-purpose computer, or processing device. Some portions of the computer resources used may be accessible via a network. The computer-executable instructions may be, for example, binary, intermediate format instructions such as those in a combined language, firmware, source code, etc. Examples of computer-executable media that can be used to store instructions, used information, and / or information created during the methods according to the examples described include magnetic disks or optical disks, flash memory, USB devices equipped with non-volatile memory, network storage devices, etc. Devices implementing the programs and methods disclosed herein may include hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and may take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, the program code or code snippets (e.g., computer program products) used to perform the necessary tasks may be stored on computer-readable or machine-readable media. A processor may perform the necessary tasks. Typical examples of form factors include laptops, smartphones, mobile phones, tablet computers or other small form factor personal computers, personal digital assistants, rack-mounted devices, standalone devices, and so on. The functionality described herein may also be embodied in peripheral devices or additional cards. As a further example, such functionality may also be implemented on a circuit board between different chips or different programs running in a single device. Instructions, media for conveying these instructions, computing resources for executing them, and other structures for supporting such computing resources are instance units for providing the functionality described in this document. In the foregoing description, various aspects of this application have been described with reference to specific embodiments; however, those skilled in the art will recognize that this application is not limited thereto. Therefore, although illustrative embodiments of this application have been described in detail herein, it should be understood that these inventive concepts can be embodied and employed differently in other ways, and the appended claims are intended to be construed as including such variations, beyond those limited by the prior art. Various features and aspects of the above-described applications can be used individually or in combination. Furthermore, embodiments can be used in any number of settings and applications beyond those described herein without departing from the broader spirit and scope of this specification. Therefore, this specification and the accompanying drawings should be considered illustrative rather than restrictive. For illustrative purposes, the methods have been described in a particular order. It should be recognized that, in alternative embodiments, these methods may be performed in a different order than that described. Those skilled in the art will understand that the less than (“<”) and greater than (“>”) symbols or terms used herein may be replaced with less than or equal to (“≦”) and greater than or equal to (“≧”) symbols without departing from the scope of this specification. When a component is described as being "configured" to perform certain operations, such configuration can be achieved, for example, by designing electronic circuits or other hardware to perform the operations, by programming programmable electronic circuits (such as microprocessors or other suitable electronic circuits) to perform the operations, or any combination thereof. The phrase “coupled to” means any component that is directly or indirectly physically connected to another component, and / or any component that communicates directly or indirectly with another component (e.g., connected to another component via a wired or wireless connection and / or other suitable communication interface). In this context, the use of "at least one" and / or "one or more" request terms or other languages in a set indicates that one or more members of that set (in any combination) satisfy the request. For example, a request term language referring to "at least one of A and B" means A, B, or A and B. In another instance, a request term language referring to "at least one of A, B, and C" means A, B, C, or A and B, or A and C, or B and C, or A and B and C. The use of "at least one" and / or "one or more" languages in a set does not limit the set to items listed in that set. For example, a declaration language referring to "at least one of A and B" could mean A, B, or A and B, and could additionally include items not listed in the set of A and B. The various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can all be implemented as electronic hardware, computer software, or a combination thereof. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described overall in relation to their functions. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art to which this invention pertains can implement the described functions in different ways for each specific application, but such implementation decisions should not be construed as a departure from the scope of this invention. The techniques described herein can also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques can be implemented in any of a variety of devices, such as general-purpose computers, wireless communication handheld devices, or integrated circuit devices having multiple uses, including applications in wireless communication handheld devices and other devices. Any feature described as a module or component can be implemented together in an integrated logic device, or separately as individual but interoperable logic devices. If implemented in software, these techniques can be implemented at least in part via a computer-readable data storage medium comprising program code, including instructions that, when executed, perform one or more of the methods described above. The computer-readable data storage medium can form part of a computer program product, which may include packaging material. Computer-readable media can include memory or data storage media, such as random access memory (RAM) (e.g., synchronous dynamic random access memory (SDRAM)), read-only memory (ROM), non-volatile random access memory (NVRAM), electronically erasable programmable read-only memory (EEPROM), FLASH memory, magnetic or optical data storage media, etc. Additionally or alternatively, these technologies can be implemented at least in part by computer-readable communication media that carries or transmits program code in the form of instructions or data structures and can be accessed, read, and / or executed by a computer, for example, to transmit signals or waveforms. The code can be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Such processors can be configured to perform any of the techniques described herein. A general-purpose processor may be a microprocessor, or a processor may be any general processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, a combination of one or more microprocessors with a DSP core, or any other such configuration. Therefore, the term "processor" as used herein may represent any of the foregoing structures, any combination of the foregoing structures, or any other structure or device suitable for implementing the techniques described herein. Furthermore, in some cases, the functionality described herein may be provided within dedicated software and / or hardware modules configured for encoding and decoding, or incorporated into a combined video transcoder (CODEC). The descriptive aspects of this case include: Sample 1: An apparatus for processing video data, comprising: at least one memory; and at least one processor coupled to the at least one memory, the at least one processor being configured to: acquire an image; and determine at least one of the width and height of a film grain composite block of the image based on at least one of the width and height of the image. Sample 2: According to the apparatus of Sample 1, the width value of the film grain composite block should be in the range of 1 to 8, including 1 and 8. Sample 3: The apparatus according to either Sample 1 or Sample 2, wherein the width value of the film grain composite block should be in the range of 8 to W, including 8 and W, where W is the maximum width of the corresponding grain pattern. Version 4: The apparatus according to any one of versions 1 to 3, wherein, in order to determine at least one of the width and height of the film grain composite block of the image based on at least one of the width and height of the image, the at least one processor is configured to: determine the width and height of the film grain composite block of the image based on the width and height of the image. State 5: The apparatus according to any one of states 1 to 4, wherein the at least one processor is configured to: determine that the width of the film grain composite block is equal to the width of the corresponding grain pattern; and set the horizontal offset for selecting the grain pattern block to 0. State 6: The apparatus according to any one of states 1 to 5, wherein the apparatus includes a decoder. Format 7: The apparatus according to any one of Formats 1 to 5, wherein the apparatus includes an encoder. Version 8: The apparatus according to any one of versions 1 to 7 also includes: a display configured to display one or more output images. Format 9: The apparatus according to any one of formats 1 to 8 also includes: a camera configured to capture one or more images. Format 10: The device according to any one of Formats 1 to 9, wherein the device is a mobile device. State 11: A method for processing video data, including operations according to states 1 to 10. Sample 12: A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to Samples 1 to 10. State 13: An apparatus for processing video data, comprising one or more units for performing operations according to states 1 to 10. Sample 14: An apparatus for processing video data, comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to: acquire video data including at least one image; and generate a plurality of grain patterns based on the video data, each of the plurality of grain patterns including a vertical cutoff frequency and a horizontal cutoff frequency. State 15: According to the apparatus of State 14, each of the plurality of particle patterns includes a particle pattern of size 32x32. State 16: The apparatus according to either State 14 or 15, wherein the horizontal cutoff frequency comes from a first set of seven available horizontal cutoff frequencies, and wherein the vertical cutoff frequency comes from a second set of seven available vertical cutoff frequencies. State 17: The apparatus according to any one of states 14 to 16, wherein the at least one processor is configured to: determine at least one cutoff frequency variable for the particle pattern among the plurality of particle patterns, at least in part by adding the value 4 to one of the seven available cutoff frequencies. State 18: According to the apparatus of State 17, in order to determine at least one of the vertical cutoff frequency or the horizontal cutoff frequency for the particle pattern, the at least one processor is configured to: determine the horizontal cutoff frequency variable for the particle pattern at least in part by adding the value 4 to the available cutoff frequency among the seven available cutoff frequencies; and determine the vertical cutoff frequency variable for the particle pattern at least in part by adding the value 4 to the available cutoff frequency among the seven available cutoff frequencies. State 19: The apparatus according to any one of states 14 to 18, wherein the apparatus includes a decoder. Format 20: The apparatus according to any one of formats 14 to 18, wherein the apparatus includes an encoder. Version 21: The apparatus according to any one of versions 14 to 20 also includes: a display configured to display one or more output images. Version 22: The apparatus according to any one of versions 14 to 21 also includes: a camera configured to capture one or more images. Format 23: The device according to any one of formats 14 to 22, wherein the device is a mobile device. Sample 24: A method for processing video data, including operations according to samples 14 to 23. Sample 25: A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to Samples 14 to 23. Mode 26: An apparatus for processing video data, comprising one or more units for performing operations according to modes 14 to 23. Sample 27: An apparatus for processing video data, comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to: acquire video data including at least one image; and generate a plurality of grain patterns based on the video data, each of the plurality of grain patterns including a grain pattern of size 32x32. State 28: The apparatus according to State 27, wherein each of the plurality of particle patterns includes a vertical cutoff frequency and a horizontal cutoff frequency. State 29: The apparatus according to State 28, wherein the horizontal cutoff frequency comes from a first group of seven available horizontal cutoff frequencies, and wherein the vertical cutoff frequency comes from a second group of seven available vertical cutoff frequencies. State 30: The apparatus according to any one of states 28 or 29, wherein the at least one processor is configured to: determine at least one cutoff frequency variable for the particle pattern in the plurality of particle patterns, at least in part by adding the value 4 to one of the seven available cutoff frequencies. State 31: According to the apparatus of State 30, in order to determine at least one of the vertical cutoff frequency or the horizontal cutoff frequency for the particle pattern, the at least one processor is configured to: determine the horizontal cutoff frequency variable for the particle pattern at least in part by adding the value 4 to the available cutoff frequency among the seven available cutoff frequencies; and determine the vertical cutoff frequency variable for the particle pattern at least in part by adding the value 4 to the available cutoff frequency among the seven available cutoff frequencies. State 32: The apparatus according to any one of states 27 to 31, wherein the apparatus includes a decoder. Format 33: The apparatus according to any one of formats 27 to 31, wherein the apparatus includes an encoder. Version 34: The apparatus according to any one of versions 27 to 33 also includes: a display configured to display one or more output images. Version 35: The apparatus according to any one of versions 27 to 34 also includes: a camera configured to capture one or more images. Format 36: The device according to any one of formats 27 to 35, wherein the device is a mobile device. Mode 37: A method for processing video data, including operations according to modes 27 to 36. Sample 38: A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to samples 27 to 36. Sample 39: An apparatus for processing video data, comprising one or more units for performing operations according to Samples 27 to 36. Sample 40: An apparatus for processing video data, comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to: acquire video data including at least one image; determine a value of a film grain application syntax element, the value of the film grain application syntax element specifying whether at least one film grain feature (FGC) message exists in the bitstream and whether film grain composition is to be applied to the encoded video data of the bitstream; and based on the video data, generate the bitstream including the encoded video data and the film grain application syntax element. State 41: The apparatus according to State 40, wherein the value of the film grain application syntax element includes a first value, the first value specifying that: the at least one FGC message exists in the bit stream, and the film grain composition will be applied to the encoded video data of the bit stream. State 42: The apparatus according to State 40, wherein the value of the film grain application syntax element includes a second value, the second value specifying that: the at least one FGC message may exist in the bit stream, and film grain composition may be applied to the encoded video data of the bit stream. State 43: The apparatus according to any one of states 40 to 42, wherein the film grain application syntax element is included in the extended field of the Sequence Parameter Set (SPS) of the bit stream. Sample 44: The apparatus according to any of the samples 40 to 42, wherein the film grain application syntax element is included in the Video Availability Information (VUI) payload extension field of the bitstream. Version 45: The apparatus according to any one of versions 40 to 44, wherein the apparatus includes an encoder. Sample 46: A method for processing video data, including operations according to samples 40 to 45. Sample 47: A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to samples 40 to 45. Mode 48: An apparatus for processing video data, comprising one or more units for performing operations according to modes 40 to 45. Sample 49: An apparatus for processing video data, comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to: obtain a bitstream including encoded video data; determine a value of a film grain application syntax element based on the bitstream, the value of the film grain application syntax element specifying whether at least one film grain feature (FGC) message exists in the bitstream and whether film grain synthesis is to be applied to the encoded video data in the bitstream; and process the encoded video data based on the value of the film grain application syntax element. State 50: The apparatus according to State 49, wherein the value of the film grain application syntax element includes a first value, the first value specifying that: the at least one FGC message exists in the bit stream, and the film grain composition will be applied to the encoded video data of the bit stream. State 51: The apparatus according to State 49, wherein the value of the film grain application syntax element includes a second value, the second value specifying that: the at least one FGC message may exist in the bit stream, and film grain composition may be applied to the encoded video data of the bit stream. State 52: The apparatus according to any one of states 49 to 51, wherein the film grain application syntax element is included in an extended field of the Sequence Parameter Set (SPS) of the bitstream. Sample 53: The apparatus according to any of Samples 49 to 51, wherein the film grain application syntax element is included in the Video Availability Information (VUI) payload extension field of the bitstream. State 54: The apparatus according to any one of states 49 to 53, wherein the apparatus includes a decoder. Mode 55: A method for processing video data, including operations according to modes 49 to 54. Sample 56: A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to samples 49 to 54. Sample 57: An apparatus for processing video data, comprising one or more units for performing operations according to samples 49 to 54. Sample 58: An apparatus for processing video data, comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to: acquire video data including at least one image; determine a value of a film grain constraint syntax element, the value of the film grain constraint syntax element specifying whether at least one film grain characteristic message including film grain relay data exists in a bitstream; and based on the video data, generate a bitstream including the encoded video data and the film grain constraint syntax element. State 59: The apparatus according to State 58, wherein the value of the film grain constraint syntax element includes a first value, the first value specifying that at least one film grain characteristic message is not present in the bit stream. State 60: The apparatus according to State 58, wherein the value of the film grain constraint syntax element includes a second value specifying that at least one film grain characteristic message may exist in the bit stream. State 61: The apparatus according to State 58, wherein the value of the film grain constraint syntax element includes a second value specifying that at least one film grain characteristic message exists in the bit stream. Version 62: The apparatus according to any one of versions 58 to 61, wherein the at least one film grain feature information is film grain feature supplement and enhancement information (SEI) information. Format 63: The apparatus according to any one of Formats 58 to 61, wherein the at least one film grain feature information is user data registered by ITU-T T.35 Supplemental Enhancement Information (SEI) message. Version 64: The apparatus according to any of versions 58 to 63, wherein the film grain application syntax element is included in the Video Usability Information (VUI) parameter field of the bitstream. State 65: The apparatus according to any one of states 58 to 63, wherein the film grain application syntax elements are included in the general constraint information syntax of the bit stream. Format 66: The apparatus according to any one of formats 58 to 65, wherein the apparatus includes an encoder. Mode 67: A method for processing video data, including operations according to modes 58 to 65. Sample 68: A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to samples 58 to 65. Mode 69: An apparatus for processing video data, comprising one or more units for performing operations according to modes 58 to 65. Sample 70: An apparatus for processing video data, comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to: obtain a bitstream including encoded video data; determine a value of a film grain constraint syntax element based on the bitstream, the value of the film grain constraint syntax element specifying whether at least one film grain characteristic message including film grain relay data exists in the bitstream; and process the encoded video data based on the value of the film grain application syntax element. State 71: The apparatus according to state 70, wherein the value of the film grain constraint syntax element includes a first value, the first value specifying that at least one film grain characteristic message is not present in the bit stream. State 72: According to the apparatus of state 70, the value of the film grain constraint syntax element includes a second value, which specifies that at least one film grain characteristic message may exist in the bit stream. State 73: The apparatus according to state 70, wherein the value of the film grain constraint syntax element includes a second value specifying that at least one film grain characteristic message exists in the bit stream. State 74: The apparatus according to any one of states 70 to 73, wherein the at least one film grain feature information is film grain feature supplement and enhancement information (SEI) information. Sample 75: The apparatus according to any of Samples 70 to 73, wherein the at least one film grain feature information is user data registered by ITU-T T.35 Supplemental Enhancement Information (SEI) message. Version 76: The apparatus according to any one of versions 70 to 75, wherein the film grain application syntax element is included in the Video Usability Information (VUI) parameter field of the bitstream. State 77: The apparatus according to any one of states 70 to 75, wherein the film grain application syntax elements are included in the general constraint information syntax of the bit stream. State 78: The apparatus according to any one of states 70 to 77, wherein the apparatus includes a decoder. Sample 79: A method for processing video data, including operations according to samples 70 to 77. Sample 80: A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to samples 70 to 77. Mode 81: An apparatus for processing video data, comprising one or more units for performing operations according to modes 70 to 77. State 82: An apparatus for processing video data, comprising: a memory; and one or more processors coupled to the memory, the one or more processors being configured to perform operations according to states 1 to 10, states 14 to 23, states 27 to 36, states 40 to 45, states 49 to 54, states 58 to 66, states 70 to 78, or any combination thereof. Sample 83: A method of processing video data, comprising: operations based on samples 1 to 10, samples 14 to 23, samples 27 to 36, samples 40 to 45, samples 49 to 54, samples 58 to 66, samples 70 to 78, or any combination thereof. Format 84: A non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations according to formats 1 to 10, formats 14 to 23, formats 27 to 36, formats 40 to 45, formats 49 to 54, formats 58 to 66, formats 70 to 78, or any combination thereof. Format 85: An apparatus for processing video data, comprising one or more units for performing operations according to formats 1 to 10, formats 14 to 23, formats 27 to 36, formats 40 to 45, formats 49 to 54, formats 58 to 66, formats 70 to 78, or any combination thereof. Sample 86: An apparatus for processing video data, comprising: at least one memory; and at least one processor coupled to the at least one memory, the at least one processor being configured to: acquire video data including an image; determine the width of a film grain composite block of the image based on at least one of a width and a height of the image; determine the height of the film grain composite block of the image as one; determine the block size of the film grain composite block based on the determined width and height; and select a grain block based on the determined block size. State 87: The apparatus according to State 86, wherein the width value of the film grain composite block is in the range of 8 to W, including 8 and W, wherein W is the maximum width of the corresponding grain pattern. According to the apparatus of the form 88 and the form 86, in order to determine the width and height of the film grain composite block of the image based on at least one of the width and height of the image, the at least one processor is configured to determine the width of the film grain composite block of the image based on the width and height of the image. State 89, the apparatus according to state 86, wherein the at least one processor is also configured to: obtain a current sampling block from the image; obtain a set of primitives from the current sampling block based on a determined block size; and determine an average brightness value for the set of primitives, and wherein, in order to select the particle block, the at least one processor is also configured to: select the particle block based on the average brightness value. The apparatus according to the sample 90 and the sample 89, wherein the set of primitives includes a row of primitives from the current sampling block, and wherein the at least one processor is configured to: determine the average brightness value of each row of primitives in the current sampling block; determine the overall average brightness value of the current sampling block based on the average brightness value of each row of primitives; and determine the intensity level based on the overall average brightness value. State 91, the apparatus according to State 90, wherein the at least one processor is configured to: select a particle pattern based on the intensity level; and randomly select at least a vertical offset, wherein in order to select the particle block, the at least one processor is also configured to: select the particle block from the particle pattern based on the vertical offset. State 92, the apparatus according to state 91, wherein the at least one processor is configured to: decode the current sample block; add a selected particle block to the decoded current sample block to generate an output current block; and output the output current block. Version 93, the apparatus according to version 86, wherein the at least one processor is configured to: determine that the width of the film grain composite block is equal to the width of the corresponding grain pattern; and set the horizontal offset for selecting the grain pattern block to 0. State 94, the apparatus according to state 86, wherein the apparatus includes a decoder. 95. The apparatus according to claim 86, wherein the apparatus includes an encoder. Version 96, the apparatus according to version 86, also includes: a display configured to display one or more output images. The apparatus according to the form 97, and the apparatus according to the form 86, also includes: a camera configured to capture one or more images. State 98, the device according to state 86, wherein the device is a mobile device. 99. A method for processing video data, the method comprising: obtaining video data including an image; determining the width of a film grain composite block of the image based on at least one of the width and height of the image; determining the height of the film grain composite block of the image as one; determining the block size of the film grain composite block based on the determined width and height; and selecting a grain block based on the determined block size. Sample 100, according to the method of Sample 99, wherein the width value of the film grain composite block is in the range of 8 to W, including 8 and W, wherein W is the maximum width of the corresponding grain pattern. According to the method of sample 99, determining the width and height of the film grain composite block of the image based on at least one of the width and height of the image includes: determining the width of the film grain composite block of the image based on the width and height of the image. The method according to the sample 99 also includes: obtaining a current sampling block from the image; obtaining a set of primitives from the current sampling block based on the determined block size; and determining the average brightness value of the set of primitives, wherein selecting the particle block includes: selecting the particle block based on the average brightness value. State 103, according to the method of state 102, wherein the set of primitives includes a row of primitives from the current sampling block, and wherein the method also includes: determining the average brightness value of each row of primitives in the current sampling block; determining the overall average brightness value of the current sampling block based on the average brightness value of each row of primitives; and determining the intensity level based on the overall average brightness value. The method according to sample 103 also includes: selecting a particle pattern based on the intensity level; and randomly selecting at least a vertical offset, wherein selecting the particle block includes: selecting the particle block from the particle pattern based on the vertical offset. State 105, according to the method of state 104, also includes: decoding the current sample block; adding the selected particle block to the decoded current sample block to generate an output current block; and outputting the output current block. The method according to sample 99 also includes: determining that the width of the film grain composite block is equal to the width of the corresponding grain pattern; and setting the horizontal offset used to select the grain pattern block to 0. 107. A non-transitory computer-readable medium having instructions stored thereon, which, when executed by at least one or more processors, cause the at least one or more processors to: acquire video data including an image; determine the width of a film grain composite block of the image based on at least one of the width and height of the image; determine the height of the film grain composite block of the image as one; determine the block size of the film grain composite block based on the determined width and height; and select a grain block based on the determined block size. State 108, a non-transitory computer-readable medium according to State 107, wherein the width value of the film grain composite block is in the range of 8 to W, including 8 and W, where W is the maximum width of the corresponding grain pattern. Version 109, a non-transitory computer-readable medium according to Version 107, wherein, in order to determine at least one of the width and height of the film grain composite of the image based on at least one of the width and height of the image, the instructions cause the at least one processor to: determine the width of the film grain composite of the image based on the width and height of the image. State 110, a non-transitory computer-readable medium according to State 107, wherein the instructions also cause the at least one processor to: obtain a current sample block from the image; obtain a set of primitives from the current sample block based on a determined block size; and determine an average brightness value for the set of primitives, and wherein, in order to select the particle block, the instructions cause the at least one processor to: select the particle block based on the average brightness value. State 111, a non-transitory computer-readable medium according to state 110, wherein the set of primitives includes a row of primitives from the current sampling block, and wherein the instructions also cause the at least one processor to: determine the average brightness value of each row of primitives in the current sampling block; determine the overall average brightness value of the current sampling block based on the average brightness value of each row of primitives; and determine the intensity level based on the overall average brightness value. State 112, a non-transitory computer-readable medium according to State 111, wherein the instructions also cause the at least one processor to: select a particle pattern based on the intensity level; and randomly select at least a vertical offset, wherein in order to select the particle block, the instructions cause the at least one processor to select the particle block from the particle pattern based on the vertical offset. State 113, a non-transitory computer-readable medium according to State 112, wherein the instructions also cause the at least one processor to: decode the current sample block; add a selected particle block to the decoded current sample block to produce an output current block; and output the output current block. State 114, a non-transitory computer-readable medium according to State 107, wherein the instructions also cause the at least one processor to: determine that the width of the film grain composite block is equal to the width of the corresponding grain pattern; and set the horizontal offset used to select the grain pattern block to 0. Mode 115: An apparatus for processing video data, comprising one or more units for performing operations according to modes 86 to 98, modes 99 to 106, modes 107 to 114, or combinations thereof. 35: Partitioning Unit; 41: Prediction Processing Unit; 42: Motion Estimation Unit; 44: Motion Compensation Unit; 46: Intra-prediction Processing Unit; 50: Summer; 52: Transform Processing Unit; 54: Quantization Unit; 56: Entropy Encoding Unit; 57: Post-processing Device; 58: Inverse Quantization Unit; 60: Inverse Transform Processing Unit; 62: Summer; 63: Filter Unit; 64: Image Memory; 79: Network Entity; 80: Entropy Decoding Unit; 81: Prediction Processing Unit; 82: Motion Compensation Unit; 84: Intra-prediction Processing Unit; 86: Inverse Quantization Unit; 88: Inverse Transform Processing Unit; 90: Adder; 91: Filter Unit; 92: Image Memory; 100: System; 102: Video Source; 104: Encoding Device; 106: Encoder Engine; 108: Storage Device; 110: Output; 112: Decoding Device; 114: Input 116: Decoder Engine 118: Storage Device 120: Communication Link 122: Video Destination Device 200: Image 202: Database 204: Average 206: Specific Particle Block 208: Pseudo-Randomization Program 210: Block Removal 212: Block Removal 214: Decoder 216: Image 218: Particle Mixing Output Image 300: Image 302: Current Block 304A: Line Buffer 304B: Line Buffer 306: Current Block 400: Example Program 402: Step 404: Step 406: Step 408: Step 410: Step 412: Step 414: Step 416: Step 418: Step 420: Step 422: Step 500: Program 502: Step 504: Step 506: Step 508: Step 510: Step The illustrative example of this case is described in detail below with reference to the following figures, in which: Figure 1 is a block diagram showing examples of encoding and decoding devices according to some of the contents of this case; Figure 2 is a block diagram illustrating a film grain synthesis workflow for the Society of Motion Picture and Television Engineers (SMPTE) Registered Public Document (RDD) 5, based on some aspects of the content of this case. Figure 3 is a block diagram showing some examples of line buffers used for film grain synthesis according to the contents of this case. Figures 4A and 4B are flowcharts illustrating a procedure for film grain synthesis according to the contents of this case. Figure 5 is a flowchart illustrating a procedure for processing video data according to the content of this case; Figure 6 is a block diagram illustrating some examples of video encoding devices according to the content of this case; and Figure 7 is a block diagram illustrating some examples of video decoding devices according to the content of this case. Domestic storage information (please note in order of storage institution, date, and number): None. International storage information (please note in order of storage country, institution, date, and number): None. 200: Figure 202: Database 204: Average 206: Specific particle blocks 208: Pseudo-randomization program 210: Remove Block 212: Remove Blocks 214: Decoder 216: Images 218: Output image of particle mixing
Claims
1. An apparatus for processing video data, comprising: At least one memory cell; and at least one processor coupled to the at least one memory, the at least one processor being configured to: acquire video data including an image; set a height of a film grain composite block of the image as a height value of a primitive; determine a width of the film grain composite block based on at least one of a width or a height of the image, wherein the determined width value is greater than the height value of a primitive and is in a range of 8 to W, including 8 and W, wherein W is a maximum width of a corresponding grain pattern; determine a block size of the film grain composite block based on the determined width and the height value of a primitive; and select a grain block based on the determined block size.
2. The apparatus according to claim 1, wherein the at least one processor is configured to: determine the width of the film grain composite block of the image based on the width and the height of the image.
3. The apparatus according to claim 1, wherein the at least one processor is also configured to: obtain a current sample block from the image; obtain a set of primitives from the current sample block based on a determined block size; determine an average brightness value for the set of primitives; and select the particle block based on the average brightness value.
4. The apparatus according to claim 3, wherein the set of primitives includes a row of primitives from the current sampling block, and wherein the at least one processor is configured to: determine an individual average brightness value for each row of primitives in the current sampling block; determine an overall average brightness value for the current sampling block based on the individual average brightness value for each row of primitives; and determine an intensity level based on the overall average brightness value.
5. The apparatus according to claim 4, wherein the at least one processor is configured to: select a particle pattern based on the intensity level; randomly select at least one vertical offset; and select the particle block from the particle pattern based on the vertical offset.
6. The apparatus according to claim 5, wherein the at least one processor includes a video decoder and is configured to: decode the current sample block; add selected particle blocks to the decoded current sample block to generate an output current block; and output the output current block.
7. The apparatus according to claim 6 also includes a display configured to display one or more images including the current block.
8. The apparatus according to claim 1, wherein the at least one processor is configured to: determine that the width of the film grain composite block is equal to the width of a corresponding grain pattern; and set a horizontal offset for selecting a block of the corresponding grain pattern to 0.
9. The apparatus according to claim 1, wherein the apparatus includes an encoder.
10. The apparatus according to claim 1 also includes: A camera configured to capture one or more images.
11. A method for processing video data, the method comprising the steps of: obtaining video data including an image; setting a height of a film grain composite block of the image as a height value of a pixel; determining a width of the film grain composite block based on at least one of a width or a height of the image, wherein the determined width value is greater than the height value of a pixel and is in a range of 8 to W, including 8 and W, wherein W is a maximum width of a corresponding grain pattern; determining a block size of the film grain composite block based on the determined width and the height value of a pixel; and selecting a grain block based on the determined block size.
12. The method according to claim 11 also includes the following steps: obtaining a current sampling block from the image; obtaining a set of primitives from the current sampling block based on a determined block size; and determining an average brightness value for the set of primitives, wherein selecting the particle block includes: The particle block is selected based on this average brightness value.
13. The method according to request 12, wherein the set of primitives includes a row of primitives from the currently sampled block, and wherein the method also includes: Determine an individual average brightness value for each row of primitives in the current sampling block; An overall average brightness value for the current sampling block is determined based on the individual average brightness value of each row of pixels; and an intensity level is determined based on the overall average brightness value.
14. The method according to request item 13 also includes the following steps: A particle pattern is selected based on this intensity level; And randomly select at least one vertical offset, wherein selecting the particle block includes: selecting the particle block from the particle pattern based on the vertical offset.
15. The method according to request item 14 also includes the following steps: decoding the current sample block; adding the selected particle block to the decoded current sample block to produce an output current block; and outputting the output current block.
16. The method according to claim 11 also includes the steps of: determining that a width of the film grain composite block is equal to the width of a corresponding grain pattern; and setting a horizontal offset for selecting a block of the corresponding grain pattern to 0.
Citation Information
Patent Citations
Use of film grain to mask compression artifacts
CN102714723A
Methods and systems for generating regional nesting messages for video pictures
CN109196868A
Spectrally adaptive noise filling tool (SANFT) for perceptual transform coding of still and moving images
US20200389673A1
Noise synthesis for digital images
WO2021127628A1