Systems and methods for memory management for image decoding

Abstract

Image and / or video coding, decoding, and / or processing systems and techniques are described. In some examples, a system decodes a batch of encoded blocks to generate decoded block data. The batch of encoded blocks includes a plurality of encoded blocks from an encoded image. The system stores the decoded block data in an area of memory. A size of the area of the memory is based on a stride associated with the encoded image. An arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image. The system outputs a decoded image based on the arrangement of the decoded block data in the area of the memory.

Description

SYSTEMS AND METHODS FOR MEMORY MANAGEMENT FOR IMAGE DECODINGFIELD

[0001] This application is related to image and / or video coding, decoding, and / or processing. More specifically, this application relates to systems and methods of performing improved image and / or video decoding, for instance by decoding blocks of encoded image data in batches, by arranging decoded block data in memory to match an arrangement of the block data in the image to reduce or prevent later rearrangement and / or stitching operations, and / or by using a graphics processing unit (GPU) for certain operations.BACKGROUND

[0002] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs) , laptop or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video gaming devices, cellular or satellite radio telephones, mobile phones (e.g., so-called “smart phones” ) , video teleconferencing devices, video streaming devices, and the like. Such devices allow video data to be processed and output for consumption. Digital video data includes large amounts of data to meet the demands of consumers and video providers. For example, consumers of video data desire video of the utmost quality, with high fidelity, resolutions, frame rates, and the like. The large amount of video data needed to meet these demands places a burden on communication networks and devices that process and store the video data.

[0003] Digital video devices can implement video coding techniques to compress video data. Video coding can be performed according to one or more video coding standards or formats. For example, video coding standards or formats include versatile video coding (VVC) , Essential Video Coding (EVC) , high-efficiency video coding (HEVC) , VP8, VP9, advanced video coding (AVC) , MPEG-2 Part 2 coding (MPEG stands for moving picture experts group) , among others, as well as proprietary video codecs / formats such as AOMedia Video 1 (AV1) that was developed by the  Alliance for Open Media and SMPTE 421 (also known as VC-1) , among others. Video coding generally utilizes prediction methods (e.g., inter prediction, intra prediction, or the like) that take advantage of redundancy present in video images or sequences. A goal of video coding techniques is to compress video data into a form that uses a lower bit rate, while avoiding or minimizing degradations to video quality. A goal of video decoding techniques is to recreate the original video data as closely as possible from the compressed video data. With ever-evolving video services becoming available, coding and decoding techniques with improved coding and decoding efficiencies are needed.

[0004] BRIEF SUMMARY

[0005] In some examples, systems and techniques are described for image and / or video coding, decoding, and / or processing devices and / or techniques. In some examples, a system decodes a batch of encoded blocks to generate decoded block data. The batch of encoded blocks includes a plurality of encoded blocks from an encoded image. The system stores the decoded block data in an area of memory. A size of the area of the memory is based on a stride associated with the encoded image. An arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image. The system outputs a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0006] In one example, an apparatus for decoding is provided. The apparatus includes a memory and one or more processors (e.g., implemented in circuitry) coupled to the memory. The one or more processors are configured to and can: decode a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image; store the decoded block data in an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; and output a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0007] In another example, a method of decoding is provided. The method includes: decoding a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image; storing the decoded block data in  an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; and outputting a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0008] In another example, a non-transitory computer-readable medium is provided that has stored thereon instructions that, when executed by one or more processors, cause the one or more processors to: decode a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image; store the decoded block data in an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; and output a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0009] In another example, an apparatus for decoding is provided. The apparatus includes: means for decoding a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image; means for storing the decoded block data in an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; and means for outputting a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0010] In some aspects, the apparatus is part of, and / or includes a wearable device, an extended reality device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device) , a head-mounted display (HMD) device, a wireless communication device, a mobile device (e.g., a mobile telephone and / or mobile handset and / or so-called “smart phone” or other mobile device) , a camera, a personal computer, a laptop computer, a server computer, a vehicle or a computing device or component of a vehicle, another device, or a combination thereof. In some aspects, the apparatus includes a camera or multiple cameras for capturing one or more images. In some aspects, the apparatus further includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the apparatuses described  above can include one or more sensors (e.g., one or more inertial measurement units (IMUs) , such as one or more gyroscopes, one or more gyrometers, one or more accelerometers, any combination thereof, and / or other sensor) .

[0011] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification of this patent, any or all drawings, and each claim.

[0012] The foregoing, together with other features and aspects, will become more apparent upon referring to the following specification, claims, and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Illustrative aspects of the present application are described in detail below with reference to the following drawing figures:

[0014] FIG. 1 is a block diagram illustrating an example of a system including an encoding device and a decoding device, in accordance with some examples;

[0015] FIG. 2 is a conceptual diagram illustrating an image and padding divided into blocks, in accordance with some examples;

[0016] FIG. 3 is a flow diagram illustrating a process for decoding an encoded image in a block-by-block fashion, in accordance with some examples;

[0017] FIG. 4A is a block diagram illustrating an arrangement of block data for an image in memory, in accordance with some examples;

[0018] FIG. 4B is a block diagram illustrating an arrangement of block data for an image for post-processing, in accordance with some examples;

[0019] FIG. 5 is a graph diagram illustrating time (in hardware speed units) spent on different aspects of a decoding process, tracked on a block-by-block basis, in accordance with some examples;

[0020] FIG. 6 is a flow diagram illustrating a process for decoding an encoded image in batches of blocks, in accordance with some examples;

[0021] FIG. 7 is a conceptual diagram illustrating a batch of blocks in the context of the image of FIG. 2, in accordance with some examples;

[0022] FIG. 8A is a block diagram illustrating a decoding process in which decoded block data is stored in memory in a first arrangement that differs from a second arrangement of the decoded block data in the image, in accordance with some examples;

[0023] FIG. 8B is a block diagram illustrating a decoding process in which decoded block data is stored in memory in an arrangement that matches the arrangement of the decoded block data in the image, in accordance with some examples;

[0024] FIG. 9A is a chart diagram illustrating time usage by processor (s) performing a decoding process that decodes an image in a block-by-block fashion, in accordance with some examples;

[0025] FIG. 9B is a chart diagram illustrating time usage by a processor (s) performing a decoding process that decodes an image in batches, in accordance with some examples;

[0026] FIG. 10A is a chart diagram illustrating time usage by processor (s) preparing a next block in a decoding process that decodes an image in a block-by-block approach, in accordance with some examples;

[0027] FIG. 10B is a chart diagram illustrating time usage by processor (s) preparing a next batch in a decoding process that decodes an image in a batch-based approach, in accordance with some examples;

[0028] FIG. 11A is a graph diagram illustrating power usage by processor (s) in a decoding process that decodes an image in a block-by-block fashion, in accordance with some examples;

[0029] FIG. 11B is a graph diagram illustrating power usage by processor (s) in a decoding process that decodes an image in batches, in accordance with some examples;

[0030] FIG. 12 is a flow diagram illustrating a codec process, in accordance with some examples; and

[0031] FIG. 13 is a diagram illustrating an example of a computing system for implementing certain aspects described herein.DETAILED DESCRIPTION

[0032] Certain aspects of this disclosure are provided below. Some of these aspects may be applied independently and some of them may be applied in combination as would be apparent to those of skill in the art. In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of aspects of the application. However, it will be apparent that various aspects may be practiced without these specific details. The figures and description are not intended to be restrictive.

[0033] The ensuing description provides example aspects only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the example aspects will provide those skilled in the art with an enabling description for implementing an example aspect. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the application as set forth in the appended claims.

[0034] A camera is a device that receives light and captures image frames, such as still images or video frames, using an image sensor. The terms “image, ” “image frame, ” and “frame” are used interchangeably herein. Cameras can be configured with a variety of image capture and image processing settings. The different settings result in images with different appearances. Some camera settings are determined and applied before or during capture of one or more image frames, such as ISO, exposure time, aperture size, f / stop, shutter speed, focus, and gain. For example, settings or parameters can be applied to an image sensor for capturing the one or more image frames. Other camera settings can configure post-processing of one or more image frames, such as alterations to contrast, brightness, saturation, sharpness, levels, curves, or colors. For example, settings or parameters can be applied to a processor (e.g., an image signal processor or ISP) for processing the one or more image frames captured by the image sensor.

[0035] Video coding devices implement video compression techniques to encode and decode video data efficiently. Video compression techniques may include applying different prediction  modes, including 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 to reduce or remove redundancy inherent in video sequences. A video encoder can partition each picture of an original video sequence into rectangular regions referred to as video blocks or coding units (described in greater detail below) . These video blocks may be encoded using a particular prediction mode.

[0036] Video blocks may be divided in one or more ways into one or more groups of smaller blocks. Blocks can include coding tree blocks, prediction blocks, transform blocks, or other suitable blocks. References generally to a “block, ” unless otherwise specified, may refer to such video blocks (e.g., coding tree blocks, coding blocks, prediction blocks, transform blocks, or other appropriate blocks or sub-blocks, as would be understood by one of ordinary skill. Further, each of these blocks may also interchangeably be referred to herein as “units” (e.g., coding tree unit (CTU) , coding unit, prediction unit (PU) , transform unit (TU) , or the like) . In some cases, a unit may indicate a coding logical unit that is encoded in a bitstream, while a block may indicate a portion of video frame buffer a process is target to.

[0037] For inter-prediction modes, a video encoder can search for a block similar to the block being encoded in a frame (or picture) located in another temporal location, referred to as a reference frame or a reference picture. The video encoder may restrict the search to a certain spatial displacement from the block to be encoded. A best match may be located using a two-dimensional (2D) motion vector that includes a horizontal displacement component and a vertical displacement component. For intra-prediction modes, a video encoder may form the predicted block using spatial prediction techniques based on data from previously encoded neighboring blocks within the same picture.

[0038] The video encoder may determine a prediction error. For example, the prediction can be determined as the difference between the pixel values in the block being encoded and the predicted block. The prediction error can also be referred to as the residual. The video encoder may also apply a transform to the prediction error (e.g., a discrete cosine transform (DCT) or other suitable transform) to generate transform coefficients. After transformation, the video encoder may quantize the transform coefficients. The quantized transform coefficients and motion vectors may be represented using syntax elements, and, along with control information, form a coded  representation of a video sequence. In some instances, the video encoder may entropy code syntax elements, thereby further reducing the number of bits needed for their representation.

[0039] The AV1 video codec (alternatively or additionally referred to herein as the AV1 video coding format) specifies a decoder that, in some examples, processes video data using a deblocking (DB) filter, a constrained directional enhancement filter (CDEF) , an upscaler, and a loop restoration (LR) filter, in that order, as part of decoding the video data. The VVC video codec (alternatively or additionally referred to herein as the VVC video coding format) specifies a decoder that, in some examples, processes video data using a deblocking (DB) filter, a sample adaptive offset (SAO) filter, and an adaptive loop filter (ALF) , in that order, as part of decoding the video data.

[0040] In some examples, the systems and methods described herein describe image and / or video coding, decoding, and / or processing devices and / or techniques. In some examples, a system decodes a batch of encoded blocks to generate decoded block data. The batch of encoded blocks includes a plurality of encoded blocks from an encoded image. The system stores the decoded block data in an area of memory. A size of the area of the memory is based on a stride associated with the encoded image. An arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image. The system outputs a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0041] The systems and methods described herein provide technical solutions to various technical problems with other decoder systems. For instance, some systems and methods for image and / or video decoding can be slow and inefficient due to time being wasted in between decoding of a first block to decoding a second block, the time wasted waiting to prepare the second block for decoding (e.g., write the second block into a buffer and / or memory) . The systems and methods described herein can improve efficiency and speed up decoding by decoding blocks in batches. For instance, the systems and methods described herein can decode a first batch of blocks and prepare the next batch of blocks for decoding (e.g., write the second batch of blocks into a buffer and / or memory) in parallel while the decoding of the first batch of blocks. By the time the decoding of the first batch of blocks is complete, the second batch of blocks is already prepared for decoding and the system can immediately start decoding the second batch of blocks, saving time and increasing efficiency of decoding.

[0042] Some systems and methods for image and / or video decoding can be slow and inefficient due to time being wasted rearranging decoded image data from a first arrangement in which the decoded image data is stored in memory to a second arrangement in which the decoded image data should be arranged to form the decoded image. However, by storing the stride and knowing the block size, the systems and methods described herein can improve efficiency and speed up decoding by ensuring that an area with specific dimensions is prepared for use in memory, with the specific dimensions being based on (and / or matching) stride dimensions associated with the encoded image. Stride can refer to a sum of a dimension of the image (e.g., the length or width of the image) plus any padding in that dimension using in the encoding and / or decoding process. For instance, the systems and methods described herein can store the decoded image data in memory in the same arrangement in which the decoded image data forms the decoded image. In this way, even though the encoded image data is decoded a block (or batch of blocks) at a time, once all of the blocks have been decoded, the area in memory stores the decoded image. The systems and methods described herein do not need to rearrange or stitch together decoded block data from different areas in memory, but rather, can simply read the full decoded image (and / or the padding) from the area in memory. In some cases, the systems and methods described herein can perform post-processing on the decoded image, which the systems and methods described herein can perform directly in the area in memory, again without needing to rearrange or stitch together decoded block data from different areas in memory.

[0043] Some systems and methods for image and / or video decoding can be slow and inefficient due to certain processes being performed using a central processing unit (CPU) . In some examples, the systems and methods described herein can improve speed and efficiency of decoding by performing such tasks using a graphics processing unit (GPU) instead of or in addition to the CPU. For instance, in some examples, the systems and methods described herein can use the GPU (in some cases also the CPU) to perform certain post-processing tasks, such as alignment adjustment, color space conversion, deblocking, or a combination thereof. Color space conversion can include, for instance, conversion between a luminosity-chroma (e.g., YUV) color space and a red-green-blue (RGB) color space, and / or between any set of color spaces discussed herein.

[0044] Various aspects of the application will be described with respect to the figures. FIG. 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 the receiving device may include an electronic device, such as a mobile or stationary telephone handset (e.g., smartphone, cellular telephone, or the like) , a desktop computer, a laptop or notebook computer, a tablet computer, a set-top box, a television, a camera, a display device, a digital media player, a video gaming console, a video streaming device, an Internet Protocol (IP) camera, or any other suitable electronic device. In some examples, the source device and the receiving device may include one or more wireless transceivers for wireless communications. The coding techniques described herein are applicable to video coding in various multimedia applications, including streaming video transmissions (e.g., over the Internet) , television broadcasts or transmissions, encoding of digital video for storage on a data storage medium, decoding of digital video stored on a data storage medium, or other applications. In some examples, system 100 can support one-way or two-way video transmission to support applications such as video conferencing, video streaming, video playback, video broadcasting, gaming, and / or video telephony.

[0045] The encoding device 104 (or encoder) can be used to encode video data using a video coding standard or protocol to generate an encoded video bitstream. Examples of video coding standards include ITU-T H. 261, ISO / IEC MPEG-1 Visual, ITU-T H. 262 or ISO / IEC MPEG-2 Visual, ITU-T H. 263, ISO / IEC MPEG-4 Visual, ITU-T H. 264 (also known as ISO / IEC MPEG-4 AVC) , including its Scalable Video Coding (SVC) and Multiview Video Coding (MVC) extensions, and High Efficiency Video Coding (HEVC) or ITU-T H. 265. Various extensions to HEVC deal with multi-layer video coding exist, including the range and screen content coding extensions, 3D video coding (3D-HEVC) and 10ultiview extensions (MV-HEVC) and scalable extension (SHVC) . The HEVC and its extensions have been developed by the Joint Collaboration Team on Video Coding (JCT-VC) as well as Joint Collaboration Team on 3D Video Coding Extension Development (JCT-3V) of ITU-T Video Coding Experts Group (VCEG) and ISO / IEC Motion Picture Experts Group (MPEG) .

[0046] MPEG and ITU-T VCEG have also formed a joint exploration video team (JVET) to explore new coding tools for the next generation of video coding standard, named Versatile Video Coding (VVC) . The reference software is called VVC Test Model (VTM) (or JEM (joint exploration model) ) . An objective of VVC is to provide a significant improvement in compression  performance over the existing HEVC standard, aiding in deployment of higher-quality video services and emerging applications (e.g., such as 560° omnidirectional immersive multimedia, high-dynamic-range (HDR) video, among others) . VP9, Alliance of Open Media (AOMedia) Video 1 (AV1) , and Essential Video Coding (EVC) are other video codecs, formats, and / or standards for which the techniques described herein can be applied.

[0047] The techniques described herein can be applied to any of the existing video codecs (e.g., High Efficiency Video Coding (HEVC) , Advanced Video Coding (AVC) , or other suitable existing video codec) , and / or can be an efficient coding tool for any video coding standards being developed and / or future video coding standards, such as, for example, VVC and / or other video coding standard in development or to be developed. For example, examples described herein can be performed using video codecs such as VVC, HEVC, AVC, and / or extensions thereof. However, the techniques and systems described herein may also be applicable to other codecs and / or coding formats, such as MPEG, JPEG (or other coding standard for still images) , VP9, AV1, extensions thereof, or other suitable coding standards already available or not yet available or developed. Accordingly, while the techniques and systems described herein may be described with reference to a particular video coding standard, one of ordinary skill in the art will appreciate that the description should not be interpreted to apply only to that particular standard.

[0048] Many embodiments described herein provide examples using the JEM model, VVC, the HEVC standard, and / or extensions thereof. However, the techniques and systems described herein may also be applicable to other coding standards, such as AVC, MPEG, JPEG (or other coding standard for still images) , extensions thereof, or other suitable coding standards already available or not yet available or developed. Accordingly, while the techniques and systems described herein may be described with reference to a particular video coding standard, one of ordinary skill in the art will appreciate that the description should not be interpreted to apply only to that particular standard.

[0049] Referring to FIG. 1, a video source 102 may provide the video data to the encoding device 104. The video source 102 may be part of the source device, or may be part of a device other than the source device. The video source 102 may include a video capture device (e.g., a video camera, a camera phone, a video phone, or the like) , a video archive containing stored video, a video server or content provider providing video data, a video feed interface receiving video from a video server  or content provider, a computer graphics system for generating computer graphics video data, a combination of such sources, or any other suitable video source.

[0050] The video data from the video source 102 may include one or more input pictures or frames. A picture or frame is a still image that, in some cases, is part of a video. In some examples, data from the video source 102 can be a still image that is not a part of a video. In HEVC, VVC, and other video coding specifications, a video sequence can include a series of pictures. A picture may include three sample arrays, denoted SL, SCb, and SCr. SL is a two-dimensional array of luma samples, SCb is a two-dimensional array of Cb chrominance samples, and SCr is a two-dimensional array of Cr chrominance samples. Chrominance samples may also be referred to herein as “chroma” samples. A pixel can refer to all three components (luma and chroma samples) for a given location in an array of a picture. In other instances, a picture may be monochrome and may only include an array of luma samples, in which case the terms pixel and sample can be used interchangeably. With respect to example techniques described herein that refer to individual samples for illustrative purposes, the same techniques can be applied to pixels (e.g., all three sample components for a given location in an array of a picture) . With respect to example techniques described herein that refer to pixels (e.g., all three sample components for a given location in an array of a picture) for illustrative purposes, the same techniques can be applied to individual samples.

[0051] Two classes of Network Abstraction Layer (NAL) units exist in the HEVC standard, including video coding layer (VCL) NAL units and non-VCL NAL units. A VCL NAL unit includes one slice or slice segment (described below) of coded picture data, and a non-VCL NAL unit includes control information that relates to one or more coded pictures. In some cases, a NAL unit can be referred to as a packet. An HEVC AU includes VCL NAL units containing coded picture data and non-VCL NAL units (if any) corresponding to the coded picture data.

[0052] NAL units may contain a sequence of bits forming a coded representation of the video data (e.g., an encoded video bitstream, a CVS of a bitstream, or the like) , such as coded representations of pictures in a video. The encoder engine 106 generates coded representations of pictures by partitioning each picture into multiple slices. A slice is independent of other slices so that information in the slice is coded without dependency on data from other slices within the same  picture. A slice includes one or more slice segments including an independent slice segment and, if present, one or more dependent slice segments that depend on previous slice segments.

[0053] In HEVC, the slices are then partitioned into coding tree blocks (CTBs) of luma samples and chroma samples. A CTB of luma samples and one or more CTBs of chroma samples, along with syntax for the samples, are referred to as a coding tree unit (CTU) . A CTU may also be referred to as a “tree block” or a “largest coding unit” (LCU) . A CTU is the basic processing unit for HEVC encoding. A CTU can be split into multiple coding units (Cus) of varying sizes. A CU contains luma and chroma sample arrays that are referred to as coding blocks (CBs) .

[0054] The luma and chroma CBs can be further split into prediction blocks (PBs) . A PB is a block of samples of the luma component or a chroma component that uses the same motion parameters for inter-prediction or intra-block copy (IBC) prediction (when available or enabled for use) . The luma PB and one or more chroma PBs, together with associated syntax, form a prediction unit (PU) . For inter-prediction, a set of motion parameters (e.g., one or more motion vectors, reference indices, or the like) is signaled in the bitstream for each PU and is used for inter-prediction of the luma PB and the one or more chroma PBs. The motion parameters can also be referred to as motion information. A CB can also be partitioned into one or more transform blocks (TBs) . A TB represents a square block of samples of a color component on which a residual transform (e.g., the same two-dimensional transform in some cases) is applied for coding a prediction residual signal. A transform unit (TU) represents the TBs of luma and chroma samples, and corresponding syntax elements. Transform coding is described in more detail below.

[0055] A size of a CU corresponds to a size of the coding mode and may be square in shape. For example, a size of a CU may be 8 x 8 samples, 16 x 16 samples, 32 x 32 samples, 64 x 64 samples, or any other appropriate size up to the size of the corresponding CTU. The phrase “N x N” is used herein to refer to pixel dimensions of a video block in terms of vertical and horizontal dimensions (e.g., 8 pixels x 8 pixels) . The pixels in a block may be arranged in rows and columns. In some embodiments, blocks may not have the same number of pixels in a horizontal direction as in a vertical direction. Syntax data associated with a CU may describe, for example, partitioning of the CU into one or more Pus. Partitioning modes may differ between whether the CU is intra-prediction mode encoded or inter-prediction mode encoded. Pus may be partitioned to be non- square in shape. Syntax data associated with a CU may also describe, for example, partitioning of the CU into one or more Tus according to a CTU. A TU can be square or non-square in shape.

[0056] According to the HEVC standard, transformations may be performed using transform units (Tus) . Tus may vary for different Cus. The Tus may be sized based on the size of Pus within a given CU. The Tus may be the same size or smaller than the Pus. In some examples, residual samples corresponding to a CU may be subdivided into smaller units using a quadtree structure known as residual quad tree (RQT) . Leaf nodes of the RQT may correspond to Tus. Pixel difference values associated with the Tus may be transformed to produce transform coefficients. The transform coefficients may then be quantized by the encoder engine 106.

[0057] Once the pictures of the video data are partitioned into Cus, the encoder engine 106 predicts each PU using a prediction mode. The prediction unit or prediction block is then subtracted from the original video data to get residuals (described below) . For each CU, a prediction mode may be signaled inside the bitstream using syntax data. A prediction mode may include intra-prediction (or intra-picture prediction) or inter-prediction (or inter-picture prediction) . Intra-prediction utilizes the correlation between spatially neighboring samples within a picture. For example, using intra-prediction, each PU is predicted from neighboring image data in the same picture using, for example, DC prediction to find an average value for the PU, planar prediction to fit a planar surface to the PU, direction prediction to extrapolate from neighboring data, or any other suitable types of prediction. Inter-prediction uses the temporal correlation between pictures in order to derive a motion-compensated prediction for a block of image samples. For example, using inter-prediction, each PU is predicted using motion compensation prediction from image data in one or more reference pictures (before or after the current picture in output order) . The decision whether to code a picture area using inter-picture or intra-picture prediction may be made, for example, at the CU level.

[0058] The encoder engine 106 and decoder engine 116 (described in more detail below) may be configured to operate according to VVC. According to VVC, a video coder (such as encoder engine 106 and / or decoder engine 116) partitions a picture into a plurality of coding tree units (CTUs) (where a CTB of luma samples and one or more CTBs of chroma samples, along with syntax for the samples, are referred to as a CTU) . The video coder can partition a CTU according to a tree structure, such as a quadtree-binary tree (QTBT) structure or Multi-Type Tree (MTT)  structure. The QTBT structure removes the concepts of multiple partition types, such as the separation between Cus, Pus, and Tus of HEVC. A QTBT structure includes two levels, including a first level partitioned according to quadtree partitioning, and a second level partitioned according to binary tree partitioning. A root node of the QTBT structure corresponds to a CTU. Leaf nodes of the binary trees correspond to coding units (Cus) .

[0059] In an MTT partitioning structure, blocks may be partitioned using a quadtree partition, a binary tree partition, and one or more types of triple tree partitions. A triple tree partition is a partition where a block is split into three sub-blocks. In some examples, a triple tree partition divides a block into three sub-blocks without dividing the original block through the center. The partitioning types in MTT (e.g., quadtree, binary tree, and tripe tree) may be symmetrical or asymmetrical.

[0060] In some examples, the video coder can use a single QTBT or MTT structure to represent each of the luminance and chrominance components, while in other examples, the video coder can use two or more QTBT or MTT structures, such as one QTBT or MTT structure for the luminance component and another QTBT or MTT structure for both chrominance components (or two QTBT and / or MTT structures for respective chrominance components) .

[0061] The video coder can be configured to use quadtree partitioning per HEVC, QTBT partitioning, MTT partitioning, or other partitioning structures. For illustrative purposes, the description herein may refer to QTBT partitioning. However, it should be understood that the techniques of this disclosure may also be applied to video coders configured to use quadtree partitioning, or other types of partitioning as well.

[0062] In some examples, the one or more slices of a picture are assigned a slice type. Slice types include an I slice, a P slice, and a B slice. An I slice (intra-frames, independently decodable) is a slice of a picture that is only coded by intra-prediction, and therefore is independently decodable since the I slice requires only the data within the frame to predict any prediction unit or prediction block of the slice. A P slice (uni-directional predicted frames) is a slice of a picture that may be coded with intra-prediction and with uni-directional inter-prediction. Each prediction unit or prediction block within a P slice is either coded with intra-prediction or inter-prediction. When the inter-prediction applies, the prediction unit or prediction block is only predicted by one  reference picture, and therefore reference samples are only from one reference region of one frame. A B slice (bi-directional predictive frames) is a slice of a picture that may be coded with intra-prediction and with inter-prediction (e.g., either bi-prediction or uni-prediction) . A prediction unit or prediction block of a B slice may be bi-directionally predicted from two reference pictures, where each picture contributes one reference region and sample sets of the two reference regions are weighted (e.g., with equal weights or with different weights) to produce the prediction signal of the bi-directional predicted block. As explained above, slices of one picture are independently coded. In some cases, a picture can be coded as just one slice.

[0063] As noted above, intra-picture prediction of a picture utilizes the correlation between spatially neighboring samples within the picture. There is a plurality of intra-prediction modes (also referred to as “intra modes” ) . In some examples, the intra prediction of a luma block includes 35 modes, including the Planar mode, DC mode, and 33 angular modes (e.g., diagonal intra prediction modes and angular modes adjacent to the diagonal intra prediction modes) . The 35 modes of the intra prediction are indexed as shown in Table 1 below. In other examples, more intra modes may be defined including prediction angles that may not already be represented by the 33 angular modes. In other examples, the prediction angles associated with the angular modes may be different from those used in HEVC.

[0064] Table 1 –Specification of intra prediction mode and associated names

[0065] Inter-picture prediction uses the temporal correlation between pictures in order to derive a motion-compensated prediction for a block of image samples. Using a translational motion model, the position of a block in a previously decoded picture (areference picture) is indicated by a motion vector (Δx, Δy) , with Δx specifying the horizontal displacement and Δy specifying the vertical displacement of the reference block relative to the position of the current block. In some cases, a motion vector (Δx, Δy) can be in integer sample accuracy (also referred to as integer  accuracy) , in which case the motion vector points to the integer-pel grid (or integer-pixel sampling grid) of the reference frame. In some cases, a motion vector (Δx, Δy) can be of fractional sample accuracy (also referred to as fractional-pel accuracy or non-integer accuracy) to more accurately capture the movement of the underlying object, without being restricted to the integer-pel grid of the reference frame. Accuracy of motion vectors may be expressed by the quantization level of the motion vectors. For example, the quantization level may be integer accuracy (e.g., 1-pixel) or fractional-pel accuracy (e.g., 1 / 4-pixel, 1 / 2-pixel, or other sub-pixel value) . Interpolation is applied on reference pictures to derive the prediction signal when the corresponding motion vector has fractional sample accuracy. For example, samples available at integer positions can be filtered (e.g., using one or more interpolation filters) to estimate values at fractional positions. The previously decoded reference picture is indicated by a reference index (refIdx) to a reference picture list. The motion vectors and reference indices can be referred to as motion parameters. Two kinds of inter-picture prediction can be performed, including uni-prediction and bi-prediction.

[0066] With inter-prediction using bi-prediction, two sets of motion parameters (Δx0, y0,refIdx0 and Δx1, y1, refIdx1) are used to generate two motion compensated predictions (from the same reference picture or possibly from different reference pictures) . For example, with bi-prediction, each prediction block uses two motion compensated prediction signals, and generates B prediction units. The two motion compensated predictions are then combined to get the final motion compensated prediction. For example, the two motion compensated predictions can be combined by averaging. In another example, weighted prediction can be used, in which case different weights can be applied to each motion compensated prediction. The reference pictures that can be used in bi-prediction are stored in two separate lists, denoted as list 0 and list 1. Motion parameters can be derived at the encoder using a motion estimation process.

[0067] With inter-prediction using uni-prediction, one set of motion parameters (Δx0, y0, refIdx0) is used to generate a motion compensated prediction from a reference picture. For example, with uni-prediction, each prediction block uses at most one motion compensated prediction signal, and generates P prediction units.

[0068] A PU may include the data (e.g., motion parameters or other suitable data) related to the prediction process. For example, when the PU is encoded using intra-prediction, the PU may include data describing an intra-prediction mode for the PU. As another example, when the PU is  encoded using inter-prediction, the PU may include data defining a motion vector for the PU. The data defining the motion vector for a PU may describe, for example, a horizontal component of the motion vector (Δx) , a vertical component of the motion vector (Δy) , a resolution for the motion vector (e.g., integer precision, one-quarter pixel precision or one-eighth pixel precision) , a reference picture to which the motion vector points, a reference index, a reference picture list (e.g., List 0, List 1, or List C) for the motion vector, or any combination thereof.

[0069] After performing prediction using intra-and / or inter-prediction, the encoding device 104 can perform transformation and quantization. For example, following prediction, the encoder engine 106 may calculate residual values corresponding to the PU. Residual values may comprise pixel difference values between the current block of pixels being coded (the PU) and the prediction block used to predict the current block (e.g., the predicted version of the current block) . For example, after generating a prediction block (e.g., issuing inter-prediction or intra-prediction) , the encoder engine 106 can generate a residual block by subtracting the prediction block produced by a prediction unit from the current block. The residual block includes a set of pixel difference values that quantify differences between pixel values of the current block and pixel values of the prediction block. In some examples, the residual block may be represented in a two-dimensional block format (e.g., a two-dimensional matrix or array of pixel values) . In such examples, the residual block is a two-dimensional representation of the pixel values.

[0070] Any residual data that may be remaining after prediction is performed is transformed using a block transform, which may be based on discrete cosine transform, discrete sine transform, an integer transform, a wavelet transform, other suitable transform function, or any combination thereof. In some cases, one or more block transforms (e.g., sizes 32 x 32, 16 x 16, 8 x 8, 4 x 4, or other suitable size) may be applied to residual data in each CU. In some embodiments, a TU may be used for the transform and quantization processes implemented by the encoder engine 106. A given CU having one or more Pus may also include one or more Tus. As described in further detail below, the residual values may be transformed into transform coefficients using the block transforms, and then may be quantized and scanned using Tus to produce serialized transform coefficients for entropy coding.

[0071] In some embodiments following intra-predictive or inter-predictive coding using Pus of a CU, the encoder engine 106 may calculate residual data for the Tus of the CU. The Pus may  comprise pixel data in the spatial domain (or pixel domain) . The Tus may comprise coefficients in the transform domain following application of a block transform. As previously noted, the residual data may correspond to pixel difference values between pixels of the unencoded picture and prediction values corresponding to the Pus. Encoder engine 106 may form the Tus including the residual data for the CU, and may then transform the Tus to produce transform coefficients for the CU.

[0072] The encoder engine 106 may perform quantization of the transform coefficients. Quantization provides further compression by quantizing the transform coefficients to reduce the amount of data used to represent the coefficients. For example, quantization may reduce the bit depth associated with some or all of the coefficients. In one example, a coefficient with an n-bit value may be rounded down to an m-bit value during quantization, with n being greater than m.

[0073] Once quantization is performed, the coded video bitstream includes quantized transform coefficients, prediction information (e.g., prediction modes, motion vectors, block vectors, or the like) , partitioning information, and any other suitable data, such as other syntax data. The different elements of the coded video bitstream may then be entropy encoded by the encoder engine 106. In some examples, the encoder engine 106 may utilize a predefined scan order to scan the quantized transform coefficients to produce a serialized vector that can be entropy encoded. In some examples, encoder engine 106 may perform an adaptive scan. After scanning the quantized transform coefficients to form a vector (e.g., a one-dimensional vector) , the encoder engine 106 may entropy encode the vector. For example, the encoder engine 106 may use context adaptive variable length coding, context adaptive binary arithmetic coding, syntax-based context-adaptive binary arithmetic coding, probability interval partitioning entropy coding, or another suitable entropy encoding technique.

[0074] As previously described, an HEVC bitstream includes a group of NAL units, including VCL NAL units and non-VCL NAL units. VCL NAL units include coded picture data forming a coded video bitstream. For example, a sequence of bits forming the coded video bitstream is present in VCL NAL units. Non-VCL NAL units may contain parameter sets with high-level information relating to the encoded video bitstream, in addition to other information. For example, a parameter set may include a video parameter set (VPS) , a sequence parameter set (SPS) , and a picture parameter set (PPS) . Examples of goals of the parameter sets include bit rate efficiency,  error resiliency, and providing systems layer interfaces. Each slice references a single active PPS, SPS, and VPS to access information that the decoding device 112 may use for decoding the slice. An identifier (ID) may be coded for each parameter set, including a VPS ID, an SPS ID, and a PPS ID. An SPS includes an SPS ID and a VPS ID. A PPS includes a PPS ID and an SPS ID. Each slice header includes a PPS ID. Using the IDs, active parameter sets can be identified for a given slice.

[0075] A PPS includes information that applies to all slices in a given picture. Because of this, all slices in a picture refer to the same PPS. Slices in different pictures may also refer to the same PPS. An SPS includes information that applies to all pictures in a same coded video sequence (CVS) or bitstream. As previously described, a coded video sequence is a series of access units (Aus) that starts with a random access point picture (e.g., an instantaneous decode reference (IDR) picture or broken link access (BLA) picture, or other appropriate random access point picture) in the base layer and with certain properties (described above) up to and not including a next AU that has a random access point picture in the base layer and with certain properties (or the end of the bitstream) . The information in an SPS may not change from picture to picture within a coded video sequence. Pictures in a coded video sequence may use the same SPS. The VPS includes information that applies to all layers within a coded video sequence or bitstream. The VPS includes a syntax structure with syntax elements that apply to entire coded video sequences. In some embodiments, the VPS, SPS, or PPS may be transmitted in-band with the encoded bitstream. In some embodiments, the VPS, SPS, or PPS may be transmitted out-of-band in a separate transmission than the NAL units containing coded video data.

[0076] A video bitstream can also include Supplemental Enhancement Information (SEI) messages. For example, an SEI NAL unit can be part of the video bitstream. In some cases, an SEI message can contain information that is not needed by the decoding process. For example, the information in an SEI message may not be essential for the decoder to decode the video pictures of the bitstream, but the decoder can be use the information to improve the display or processing of the pictures (e.g., the decoded output) . The information in an SEI message can be embedded metadata. In one illustrative example, the information in an SEI message could be used by decoder-side entities to improve the viewability of the content. In some instances, certain application standards may mandate the presence of such SEI messages in the bitstream so that the  improvement in quality can be brought to all devices that conform to the application standard (e.g., the carriage of the frame-packing SEI message for frame-compatible plano-stereoscopic 3DTV video format, where the SEI message is carried for every frame of the video, handling of a recovery point SEI message, use of pan-scan scan rectangle SEI message in DVB, in addition to many other examples) .

[0077] The output 110 of the encoding device 104 may send the NAL units making up the encoded video bitstream data over the communications link 120 to the decoding device 112 of the receiving device. The input 114 of the decoding device 112 may receive the NAL units. The communications link 120 may include a channel provided by a wireless network, a wired network, or a combination of a wired and wireless network. A 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 network, a packet-based network, WiFiTM, radio frequency (RF) , UWB, WiFi-Direct, cellular, Long-Term Evolution (LTE) , WiMaxTM, or the like) . A wired network may include any wired interface (e.g., fiber, ethernet, powerline ethernet, ethernet over coaxial cable, digital signal line (DSL) , or the like) . The wired and / or wireless networks may be implemented using various equipment, such as base stations, routers, access points, bridges, gateways, switches, or the like. The encoded video bitstream data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the receiving device.

[0078] In some examples, the encoding device 104 may store encoded video bitstream data in storage 108. The output 110 may retrieve the encoded video bitstream data from the encoder engine 106 or from the storage 108. Storage 108 may include any of a variety of distributed or locally accessed data storage media. For example, the storage 108 may include a hard drive, a storage disc, flash memory, volatile or non-volatile memory, or any other suitable digital storage media for storing encoded video data. The storage 108 can also include a decoded picture buffer (DPB) for storing reference pictures for use in inter-prediction. In a further example, the storage 108 can correspond to a file server or another intermediate storage device that may store the encoded video generated by the source device. In such cases, the receiving device including the decoding device 112 can access stored video data from the storage device via streaming or download. The file server may be any type of server capable of storing encoded video data and transmitting that  encoded video data to the receiving device. Example file servers include a web server (e.g., for a website) , an FTP server, network attached storage (NAS) devices, or a local disk drive. The receiving device may access the encoded video data through any standard data connection, including an Internet connection. This may include a wireless channel (e.g., a Wi-Fi connection) , a wired connection (e.g., DSL, cable modem, etc. ) , or a combination of both that is suitable for accessing encoded video data stored on a file server. The transmission of encoded video data from the storage 108 may be a streaming transmission, a download transmission, or a combination thereof.

[0079] The input 114 of the decoding device 112 receives the encoded video bitstream data and may provide the video bitstream data to the decoder engine 116, or to storage 118 for later use by the decoder engine 116. For example, the storage 118 can include a DPB for storing reference pictures for use in inter-prediction. The receiving device including the decoding device 112 can receive the encoded video data to be decoded via the storage 108. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the receiving device. The communication medium for transmitted the encoded video data can comprise any wireless or wired communication medium, such as a 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 routers, switches, base stations, or any other equipment that may be useful to facilitate communication from the source device to the receiving device.

[0080] The decoder engine 116 may decode the encoded video bitstream data by entropy decoding (e.g., using an entropy decoder) and extracting the elements of one or more coded video sequences making up the encoded video data. The decoder engine 116 may then rescale and perform an inverse transform on the encoded video bitstream data. Residual data is then passed to a prediction stage of the decoder engine 116. The decoder engine 116 then predicts a block of pixels (e.g., a PU) . In some examples, the prediction is added to the output of the inverse transform (the residual data) .

[0081] The decoding device 112 may output the decoded video to a 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 aspects, the video destination device 122 may be part of the receiving device that includes the decoding device 112. In some aspects, the video destination device 122 may be part of a separate device other than the receiving device.

[0082] In some embodiments, the video encoding device 104 and / or the video decoding device 112 may be integrated with an audio encoding device and audio decoding device, respectively. The video encoding device 104 and / or the video decoding device 112 may also include other hardware or software that is necessary to implement the coding techniques described above, such as one or more microprocessors, digital signal processors (DSPs) , application specific integrated circuits (ASICs) , field programmable gate arrays (FPGAs) , discrete logic, software, hardware, firmware or any combinations thereof. The video encoding device 104 and the video decoding device 112 may be integrated as part of a combined encoder / decoder (codec) in a respective device.

[0083] The example system shown in FIG. 1 is one illustrative example that can be used herein. Techniques for processing video data using the techniques described herein can be performed by any digital video encoding and / or decoding device. Although generally the techniques of this disclosure are performed by a video encoding device or a video decoding device, the techniques may also be performed by a combined video encoder-decoder, typically referred to as a “CODEC. ” Moreover, the techniques of this disclosure may also be performed by a video preprocessor. The source device and the receiving device are merely examples of such coding devices in which the source device generates coded video data for transmission to the receiving device. In some examples, the source and receiving devices may operate in a substantially symmetrical manner such that each of the devices include video encoding and decoding components. Hence, example systems may support one-way or two-way video transmission between video devices, e.g., for video streaming, video playback, video broadcasting, or video telephony.

[0084] Extensions to the HEVC standard include the Multiview Video Coding extension, referred to as MV-HEVC, and the Scalable Video Coding extension, referred to as SHVC. The MV-HEVC and SHVC extensions share the concept of layered coding, with different layers being included in the encoded video bitstream. Each layer in a coded video sequence is addressed by a unique layer identifier (ID) . A layer ID may be present in a header of a NAL unit to identify a layer with which the NAL unit is associated. In MV-HEVC, different layers can represent different views of the same scene in the video bitstream. In SHVC, different scalable layers are provided  that represent the video bitstream in different spatial resolutions (or picture resolution) or in different reconstruction fidelities. The scalable layers may include a base layer (with layer ID = 0) and one or more enhancement layers (with layer IDs = 1, 2, …n) . The base layer may conform to a profile of the first version of HEVC, and represents the lowest available layer in a bitstream. The enhancement layers have increased spatial resolution, temporal resolution or frame rate, and / or reconstruction fidelity (or quality) as compared to the base layer. The enhancement layers are hierarchically organized and may (or may not) depend on lower layers. In some examples, the different layers may be coded using a single standard codec (e.g., all layers are encoded using HEVC, SHVC, or other coding standard) . In some examples, different layers may be coded using a multi-standard codec. For example, a base layer may be coded using AVC, while one or more enhancement layers may be coded using SHVC and / or MV-HEVC extensions to the HEVC standard.

[0085] In general, a layer includes a set of VCL NAL units and a corresponding set of non-VCL NAL units. The NAL units are assigned a particular layer ID value. Layers can be hierarchical in the sense that a layer may depend on a lower layer. A layer set refers to a set of layers represented within a bitstream that are self-contained, meaning that the layers within a layer set can depend on other layers in the layer set in the decoding process, but do not depend on any other layers for decoding. Accordingly, the layers in a layer set can form an independent bitstream that can represent video content. The set of layers in a layer set may be obtained from another bitstream by operation of a sub-bitstream extraction process. A layer set may correspond to the set of layers that is to be decoded when a decoder wants to operate according to certain parameters.

[0086] As described above, for each block, a set of motion information (also referred to herein as motion parameters) can be available. A set of motion information contains motion information for forward and backward prediction directions. The forward and backward prediction directions are two prediction directions of a bi-directional prediction mode, in which case the terms “forward” and “backward” do not necessarily have a geometrical meaning. Instead, “forward” and “backward” correspond to reference picture list 0 (RefPicList0 or L0) and reference picture list 1 (RefPicList1 or L1) of a current picture. In some examples, when only one reference picture list is available for a picture or slice, only RefPicList0 is available and the motion information of each block of a slice is always forward.

[0087] In some cases, a motion vector together with its reference index is used in coding processes (e.g., motion compensation) . Such a motion vector with the associated reference index is denoted as a uni-predictive set of motion information. For each prediction direction, the motion information can contain a reference index and a motion vector. In some cases, for simplicity, a motion vector itself may be referred in a way that it is assumed that it has an associated reference index. A reference index is used to identify a reference picture in the current reference picture list (RefPicList0 or RefPicList1) . A motion vector has a horizontal and a vertical component that provide an offset from the coordinate position in the current picture to the coordinates in the reference picture identified by the reference index. For example, a reference index can indicate a particular reference picture that should be used for a block in a current picture, and the motion vector can indicate where in the reference picture the best-matched block (the block that best matches the current block) is in the reference picture.

[0088] A picture order count (POC) can be used in video coding standards to identify a display order of a picture. Although there are cases for which two pictures within one coded video sequence may have the same POC value, it typically does not happen within a coded video sequence. When multiple coded video sequences are present in a bitstream, pictures with a same value of POC may be closer to each other in terms of decoding order. POC values of pictures can be used for reference picture list construction, derivation of reference picture set as in HEVC, and motion vector scaling.

[0089] In H. 264 / AVC, each inter macroblock (MB) may be partitioned in four different ways, including: one 16x16 MB partition; two 16x8 MB partitions; two 8x16 MB partitions; and four 8x8 MB partitions. Different MB partitions in one MB may have different reference index values for each direction (RefPicList0 or RefPicList1) . In some cases, when an MB is not partitioned into four 8x8 MB partitions, it can have only one motion vector for each MB partition in each direction. In some cases, when an MB is partitioned into four 8x8 MB partitions, each 8x8 MB partition can be further partitioned into sub-blocks, in which case each sub-block can have a different motion vector in each direction. In some examples, there are four different ways to get sub-blocks from an 8x8 MB partition, including: one 8x8 sub-block; two 8x4 sub-blocks; two 4x8 sub-blocks; and four 4x4 sub-blocks. Each sub-block can have a different motion vector in each direction. Therefore, a motion vector is present in a level equal to higher than sub-block.

[0090] In AVC, a temporal direct mode can be enabled at either the MB level or the MB partition level for skip and / or direct mode in B slices. For each MB partition, the motion vectors of the block co-located with the current MB partition in the RefPicList1 [0 ] of the current block are used to derive the motion vectors. Each motion vector in the co-located block is scaled based on POC distances.

[0091] A spatial direct mode can also be performed in AVC. For example, in AVC, a direct mode can also predict motion information from the spatial neighbors.

[0092] In HEVC, the largest coding unit in a slice is called a coding tree block (CTB) . A CTB contains a quad-tree, the nodes of which are coding units. The size of a CTB can range from 16x16 to 64x64 in the HEVC main profile. In some cases, 8x8 CTB sizes can be supported. A coding unit (CU) could be the same size of a CTB and as small as 8x8. In some cases, each coding unit is coded with one mode. When a CU is inter-coded, the CU may be further partitioned into 2 or 4 prediction units (Pus) , or may become just one PU when further partition does not apply. When two Pus are present in one CU, they can be half size rectangles or two rectangles with 1 / 4 or 3 / 4 size of the CU.

[0093] When the CU is inter-coded, one set of motion information is present for each PU. In addition, each PU is coded with a unique inter-prediction mode to derive the set of motion information.

[0094] For motion prediction in HEVC, there are two inter-prediction modes, including merge mode and advanced motion vector prediction (AMVP) mode for a prediction unit (PU) . Skip is considered as a special case of merge. In either AMVP or merge mode, a motion vector (MV) candidate list is maintained for multiple motion vector predictors. The motion vector (s) , as well as reference indices in the merge mode, of the current PU are generated by taking one candidate from the MV candidate list. In some examples, as described below, one or more stored local illumination compensation (LIC) flags can be included along with stored motion vectors in a MV candidate list.

[0095] In examples where a MV candidate list is used for motion prediction (and where applicable, illumination compensation) of a block, the MV candidate list may be constructed by the encoding device and the decoding device separately. For instance, the MV candidate list can  be generated by an encoding device when encoding a block, and can be generated by a decoding device when decoding the block. Information related to motion information candidates in the MV candidate list (e.g. information related to one or more motion vectors, information related to one or more LIC flags which can be stored in the MV candidate list in some cases, and / or other information) , can be signaled between the encoding device and the decoding device. For example, in the merge mode, index values to the stored motion information candidates can be signaled from an encoding device to a decoding device (e.g., in a syntax structure, such as the picture parameter set (PPS) , sequence parameter set (SPS) , video parameter set (VPS) , a slice header, a supplemental enhancement information (SEI) message sent in or separately from the video bitstream, and / or other signaling) . The decoding device can construct a MV candidate list and use the signaled references or indexes to obtain one or more motion information candidates from the constructed MV candidate list to use for motion compensation prediction. For example, the decoding device 112 may construct a MV candidate list and use a motion vector (and in some cases an LIC flag) from an indexed location for motion prediction of the block. In the case of AMVP mode, in addition to the references or indexes, differences or residual values may also be signaled as deltas. For example, for the AMVP mode, the decoding device can construct one or more MV candidate lists and apply the delta values to one or more motion information candidates obtained using the signaled index values in performing motion compensation prediction of the block.

[0096] In some examples, the MV candidate list contains up to five candidates for the merge mode and two candidates for the AMVP mode. In other examples, different numbers of candidates can be included in a MV candidate list for merge mode and / or AMVP mode. A merge candidate may contain a set of motion information. For example, a set of motion information can include motion vectors corresponding to both reference picture lists (list 0 and list 1) and the reference indices. If a merge candidate is identified by a merge index, the reference pictures are used for the prediction of the current blocks, as well as the associated motion vectors are determined. However, under AMVP mode, for each potential prediction direction from either list 0 or list 1, a reference index needs to be explicitly signaled, together with an MVP index to the MV candidate list since the AMVP candidate contains only a motion vector. In AMVP mode, the predicted motion vectors can be further refined.

[0097] As can be seen above, a merge candidate corresponds to a full setof motion information, while an AMVP candidate contains just one motion vector for a specific prediction direction and reference index. The candidates for both modes arederived similarly from the same spatial and temporal neighboring blocks.

[0098] In some examples, merge mode allows an inter-predicted PU to inherit the same motion vector or vectors, prediction direction, and reference picture index orindices from an inter-predicted PU that includes a motion data position selected from a group of spatially neighboring motion data positions and one of two temporally co-located motion data positions. For AMVP mode, motion vector or vectors ofa PU can be predicatively codedrelative to one or more motion vector predictors (MVPs) from an AMVP candidate list constructed by an encoder and / or a decoder. In some instances, for single direction inter-prediction of a PU, the encoder and / or decoder can generate a single AMVPcandidate list. In some instances, for bi-directional prediction of a PU, the encoder and / or decoder can generate two AMVP candidate lists, one using motion data of spatial and temporal neighboring Pus from the forward prediction direction and one using motion data of spatial and temporal neighboring Pus from the backward prediction direction.

[0099] FIG. 2 is a conceptual diagram 200 illustrating an image 205 and padding divided into blocks. The padding includes horizontal padding 220 tothe right of the rightedge of the image 205 and vertical padding 225 belowthe bottom edge of the image205. The horizontal stride 230 can refer to the sum of the width of the image205 (e.g., the horizontal dimension of the image) plus the horizontal padding 220. The vertical stride235 can refer to the sum of the height of the image 205 (e.g., the vertical dimension of the image) plus the vertical padding 225. The image 205 illustrated in FIG. 2 depicts a woman walking adog in a park. The padding (e.g., the horizontal padding 220 and the vertical padding 225) is illustrated as an area that is shaded with diagonal stripes.

[0100] In some examples, a system (e.g., a processor and / or a memory) can be optimized for coding, decoding, and / or processing image (s) of a certain size. In an illustrative example, a system can be optimized for coding, decoding, and / or processing image (s) having dimensions of 512×512 pixels. However, many cameras capture images at higher resolutions. For instance, in some  examples, a 64 megapixel can have a resolution of 9248×6844 pixels. In some examples, the image 205 is a 64 megapixel image with a resolution of 9248×6844 pixels. In such examples, a system can divide the image into smaller blocks, with each block having dimensions of 512×512 pixels. The system can then code, decode, and / or process the image 205 in a piecewise fashion by coding, decoding, and / or processing the individual blocks of the image, then reconstructing the whole image by arranging the decoded blocks back into the arrangement in which the blocks were originally arranged in the image.

[0101] In an illustrated example, the image 205 is a 64 megapixel image with a resolution of 9248×6844 pixels. In an illustrated examples, the blocks have dimensions of 512×512 pixels. Neither 9248 nor 6844 divides evenly by 512. For instance, 9248 / 512 = 18.0625. Similarly, 6844 / 512 = 13.3671875. Thus, to store the image 205 in a set of blocks have dimensions of 512×512 pixels, the system divides the image 205 into 266 blocks, the 266 blocks arranged in a grid or lattice of blocks having a width (horizontal dimension) of 19 blocks and a height (vertical dimension) of 14 blocks. The columns of blocks are labeled zero through 18, and the rows of blocks are labeled zero through 13. Because 9248 / 512 = 18.0625, the 19th column of blocks (e.g., the rightmost column of blocks) is mostly padding (e.g., horizontal padding 220) . Because 6844 / 512 = 13.3671875, the 14th row of blocks (e.g., the bottom row of blocks) is partially padding (e.g., vertical padding 225) . In the example where the image 205 is a 64 megapixel image with a resolution of 9248×6844 pixels and the blocks have dimensions of 512×512 pixels, the horizontal stride 230 is 512×19 = 9728 pixels, while the vertical stride 235 is 512×14 = 7168 pixels.

[0102] In some cases, the term block as used herein can instead be referred to as a frame, an iframe, a tile, a superblock, a sub-block, a unit, a coding tree unit (CTU) , a coding unit, a prediction unit (PU) , a transform unit (TU) , or a combination thereof. In some examples, the image 205 is a high efficiency image file format (HEIF) image, a joint photographic experts group (JPEG) image, portable network graphics (PNG) image, a graphics interchange format (GIF) image, a bitmap (BMP) image, a tagged image file format (TIFF) image, another type of image, a video frame of a high efficiency video coding (HEVC) video, a video frame of a video coded using a H. 265 codec, a video frame of a video coded using a H. 264 codec, a video frame of a video coded using an AOMedia Video 1 (AV1) codec, a video frame of a video coded using a versatile video coding  (VVC) codec, a video frame of a video coded using another type of codec, or a combination thereof.

[0103] FIG. 3 is a flow diagram illustrating a process 300 for decoding an encoded image in a block-by-block fashion. The process 300 may be performed by a codec system. In some examples, the codec system includes a codec, an encoder, the video source 102, the encoding device 104, the encoding engine 106, the storage 108, the output 110, the communications link 120, a decoder, the decoding device 112, the input 114, the decoder engine 116, the storage 118, the video destination device 122, the decoding device 112, the decoder engine 116, an encoder, the encoding device 104, the encoder engine 106, the codec system that performs the process 600, the memory 810, the processor (s) of FIGs. 9A-9B, the processor (s) of FIGs. 10A-10B, the driver 1010, the buffer 1015, the firmware and / or hardware 1020, the processor (s) of FIGs. 11A-11B, the codec system that performs the process 1200, the computing system 1300, the processor 1310, an apparatus, a non-transitory computer-readable medium that stores instructions for execution by one or more processors, a mobile handset, a head-mounted display (HMD) , a wireless communication device, a central processing unit (CPU) , a graphics processing unit (GPU) , an accelerated processing unit (APU) , an application-specific integrated circuits (ASIC) , a field programmable gate arrays (FPGA) , or a combination thereof.

[0104] At operation 305, the codec system (or at least one component thereof) is configured to, and can, create (e.g., using a driver) a decoding queue. At operation 310, the codec system (or at least one component thereof) is configured to, and can, receive (e.g., at the driver) encoded blocks on a block-by-block basis in the decoding queue.

[0105] At loop 315, the codec system (or at least one component thereof) is configured to, and can initiate a loop 315 that processes (decodes) each encoded block of the encoded image on a block-by-block basis. For instance, for each block, the loop 315 performs operation 320, operation 325, operation 330, operation 335, operation 340, and / or operation 345.

[0106] At operation 320, the codec system (or at least one component thereof) is configured to, and can, deliver (e.g., from the driver) the encoded block to firmware, treating the block as a whole image frame. At operation 325, the codec system (or at least one component thereof) is configured to, and can, prepare (e.g., by the firmware) the hardware register programming for image decoding  of the block (e.g., preparing the hardware register programming to decode an imaging having size 512×512 pixels) . At operation 330, the codec system (or at least one component thereof) is configured to, and can, launch (e.g., by the firmware) the hardware to decode the block, to generate a decoded block. At operation 335, the codec system (or at least one component thereof) is configured to, and can, return (from the firmware) the decoded block to the driver (e.g., to a memory associated with the driver) , for instance by returning a frame buffer to the driver. In some examples, the frame buffer can be a YUV frame buffer having dimensions 512×512 pixels.

[0107] At operation 340, the codec system (or at least one component thereof) is configured to, and can, call (e.g., from the driver) the processor (e.g., CPU) to perform post-processing of the decoded block. In some examples, post-processing can include alignment adjustment (s) , color space conversion (e.g., YUV to RGB) , and / or application of a deblocking filter. At operation 345, the codec system (or at least one component thereof) is configured to, and can, start (e.g., by the driver) arranging and / or stitching each decoded block (e.g., having dimensions 512×512 pixels) together to the other blocks in the image (e.g., 64 MP image) that have been decoded so far according to the arrangement of the original blocks in the original image. Eventually, the loop 315 completes once the codec system processes (e.g., decodes, performs post-processing, and arranges and stitches together) all of the blocks to generate the full decoded image.

[0108] FIG. 4A is a block diagram illustrating an arrangement 400 of block data for an image in memory. In some examples, when the firmware calls the hardware to perform the decoding of the blocks (e.g., at operation 325 and / or operation 330) , the firmware writes the block data into memory (e.g., double data rate (DDR) memory) in raster scan order as a line of block data from a set of blocks (e.g., a row of blocks or a column of blocks) that includes blocks 410A-410H. Thus, the arrangement 400 of block data is the line of block data. In the example illustrated in FIG. 4A, the block data from the set of blocks 410A-410H is arranged in a column of blocks in memory, with block 410A at the top, then block 410B below block 410A, block 410C below block 410B, block 410D below block 410C, block 410E below block 410D, block 410F below block 410E, block 410G below block 410F, and block 410H below block 410G. In some examples, the hardware reads the block data from the memory in raster scan order from the line of block data from the set of blocks that includes blocks 410A-410H. The raster scan order of the firmware  writing the block data to the memory, and / or of the hardware reading the block data from the memory, is illustrated using arrows with dashed lines.

[0109] FIG. 4B is a block diagram illustrating an arrangement 450 of block data for an image for post-processing. The post-processing can include alignment adjustment that can rearrange blocks relative to how the blocks are arranged in memory. Alignment adjustment can be referred to as realignment, readjustment, rearranging of blocks, rearrangement, arrangement adjustment, or a combination thereof. In the example illustrated in FIG. 4B, the horizontal stride (e.g., horizontal stride 230) is four blocks in length (e.g., the horizontal stride being 512×4 = 2048 pixels if each block has dimensions 512×512 pixels) . Thus, to rearrange the block data into the arrangement 450 for post-processing (and for eventual output of the decoded image) , the driver, firmware, and / or processor (e.g., CPU and / or GPU) can rearrange the block data for the blocks 410A-410H so that blocks 410A-410D are in a top row of blocks, and so that blocks 410E-410H are in a bottom row of blocks beneath the top row of blocks. The arrangement 450 may match the arrangement of block data in the original image. In some examples, the post-processing can include color space conversion (e.g., YUV to RGB or vice versa) , application of a deblocking filter (and / or one or more other filters) or a combination thereof. In some examples, such post-processing tasks can by applied to the block data in raster scan order across the arrangement 450 of block data, for instance with the raster scan order illustrated using arrows with dashed lines.

[0110] To make FIGs. 4A-4B easier to read, the raster scan order is illustrated as if each block had only four rows of pixels, even though it should be understood that each block can have more or fewer rows of pixels. For instance, if each of the blocks has dimensions 512×512 pixels as discussed above, then each block can include 512 rows of pixels and 512 columns of pixels. In some examples, the blocks 410A-410H are still encoded as stored in memory in FIG. 4A, for instance as conveyed from the firmware to the hardware. In some examples, the blocks 410A-410H are decoded as stored in memory in FIG. 4A, for instance as conveyed back from the hardware to the firmware. In some examples, blocks 410A-410H are decoded as stored in memory in FIG. 4B.

[0111] FIG. 5 is a graph diagram 500 illustrating time (in hardware speed units 505) spent on different aspects of a decoding process, tracked on a block-by-block basis. Each hardware speed unit of the hardware speed units 505 can represent a specific number of cycles (e.g., CPU cycles,  GPU cycles, clock cycles, and / or other hardware cycles) and / or time taken by these cycles. The vertical axis in the graph diagram 500 measures time in hardware speed units 505, while the horizontal axis tracks block numbers 510 from 1 to 266. In some examples, hardware decoding of a block (e.g., operation 330) is generally a fast and efficient process. For instance, the graph diagram 500 includes a hardware decoding curve 520, illustrated as a dashed line, that identifies that hardware decoding remains relatively low across the entire decoding process (e.g., from block 1 to block 266) , never exceeding 300 hardware speed units. The graph diagram 500 also includes a waiting time curve 525 that tracks waiting time between hardware calls (e.g., from one instance of operation 330 to the next instance of operation 330 in the loop 315) . The waiting time curve 525 is illustrated This waiting time can include moving and / or rearranging of data between buffer (s) and / or memory (e.g., DDR memory) , for instance as illustrated in FIGs. 10A-10B. The waiting time curve 525 includes numerous peaks 530, some reaching 200 or even 250 hardware speed units. During the waiting time tracked along the waiting time curve 525, the hardware (for decoding) is generally sitting idle, waiting for the driver and / or firmware to prepare the next block.

[0112] As shown in the graph diagram 500, waiting time accounts for a significant proportion (e.g., approximately 80%) of the total time used for the full decoding process for the full image. In an illustrative example, the total time for the full decoding process for the full image is approximately 400 ms. Of this, the hardware decoding (e.g., operation 330) takes up only 100 (number is only for illustrative purpose) . The waiting time between two hardware calls (e.g., from one instance of operation 330 to the next instance of operation 330 in the loop 315) can takes up approximately 200 ms. Initializing and finalizing operations can take up approximately 100 ms. Initializing and finalizing operations can include, for instance, driver session creation and destruction per image, block-based post-processing, transfer between one buffer (e.g., Codec2 buffer) and another buffer (e.g., MediaCodec buffer) , rearranging and / or stitching of decoded block data (e.g. in the YUV space) , color space conversion (e.g., from the YUV color space to the RGB color space) , padding removal (e.g., removal of the horizontal padding 220 and / or the vertical padding 225) , application of a deblocking filter, or a combination thereof.

[0113] In an illustrative example, a system decoding 64 MP video frames of a video using the process 300 is only able to achieve a decoding rate of 2.5 video frames per second (fps) , primarily slowed down by all of the waiting time shown along the waiting time curve 525 of the graph  diagram 500. A decoding frame rate of 10 video frames per second prevents decoding of frames on the fly, since videos are often captured at higher frame rates like 26 frames per second (fps) , 30 fps, 60 fps, 90 fps, or 120 fps. Certain systems and methods discussed herein, such as the process 600 and the processes illustrated in FIGs. 8B, 9B, 10B, and 11B, can reduce waiting time significantly by processing blocks in batches and / or arranging the block data in memory according to an arrangement that matches the arrangement of block data in the image (e.g., arrangement 450) rather than a different arrangement (e.g., arrangement 400) . Such improvements can prevent the peaks 530 and in some cases preventing a vast majority of the time during which the hardware is idle (e.g., see FIG. 9B) .

[0114] FIG. 6 is a flow diagram illustrating a process 600 for decoding an encoded image in batches of blocks. The process 600 may be performed by a codec system. In some examples, the codec system includes a codec, an encoder, the video source 102, the encoding device 104, the encoding engine 106, the storage 108, the output 110, the communications link 120, a decoder, the decoding device 112, the input 114, the decoder engine 116, the storage 118, the video destination device 122, the decoding device 112, the decoder engine 116, an encoder, the encoding device 104, the encoder engine 106, the codec system that performs the process 300, the memory 810, the processor (s) of FIGs. 9A-9B, the processor (s) of FIGs. 10A-10B, the driver 1010, the buffer 1015, the firmware and / or hardware 1020, the processor (s) of FIGs. 11A-11B, the codec system that performs the process 1200, the computing system 1300, the processor 1310, an apparatus, a non-transitory computer-readable medium that stores instructions for execution by one or more processors, a mobile handset, an HMD, a wireless communication device, a CPU, a GPU, an APU, an ASIC, an FPGA, or a combination thereof.

[0115] At operation 605, the codec system (or at least one component thereof) is configured to, and can, create (e.g., using a driver) a decoding queue. At operation 610, the codec system (or at least one component thereof) is configured to, and can, receive (e.g., at the driver) encoded blocks on a block-by-block basis in the decoding queue, and can parse a batch of the encoded blocks to store the batch of encoded blocks in a buffer. At operation 615, the codec system (or at least one component thereof) is configured to, and can, add (e.g., at the driver) an interface to the firmware, and can deliver (e.g., from the driver to the firmware via the interface) image information. The image information can include, for instance, a width of the image (e.g., with of the image 205) , a  height of the image (e.g., height of the image 205) , a horizontal stride (e.g., horizontal stride 230) of the image, and / or a vertical stride (e.g., vertical stride 235) of the image.

[0116] At loop 620, the codec system (or at least one component thereof) is configured to, and can initiate a loop 620 that processes (decodes) each batch of encoded blocks of the encoded image on a batch-by-batch basis. For instance, for each batch of blocks, the loop 620 performs operation 625, operation 630, operation 635, and / or operation 640. In some examples, a batch of blocks can include 24 blocks, 48 blocks, 64 blocks, 128 blocks, 256 blocks, or another amount of blocks. The batch 705 of FIG. 7 illustrates an example of a batch of blocks.

[0117] At operation 625, the codec system (or at least one component thereof) is configured to, and can, deliver (e.g., from the driver) the batch of encoded blocks to the firmware. At operation 630, the codec system (or at least one component thereof) is configured to, and can, prepare (e.g., by the firmware) the hardware register programming for image decoding of blocks (e.g., preparing the hardware register programming to decode an imaging having size 512×512 pixels) . In some examples, the hardware register programming can be re-used by the hardware for decoding each block of the batch. At operation 635, the codec system (or at least one component thereof) is configured to, and can, launch (e.g., by the firmware) the hardware to decode all of the blocks in the batch, to generate decoded block data (e.g., a batch of decoded blocks) . At operation 640, the codec system (or at least one component thereof) is configured to, and can, store and / or arrange (by the firmware) the decoded blocks in a stride-aligned area of memory (e.g., DDR memory) . The size of the area of memory can match the stride (s) associated with the image. For instance, the width of the area of memory can match a horizontal stride (e.g., horizontal stride 230, for instance being 9728 pixels) associated with the image, and the height of the area of memory can match a vertical stride (e.g., vertical stride 235, for instance being 7168 pixels) associated with the image. Eventually, the loop 620 completes once the codec system processes (e.g., decodes and / or arranges and stores) all of the batches of blocks to store and / or generate the full decoded image.

[0118] At operation 645, the codec system (or at least one component thereof) is configured to, and can, receive (e.g. at the driver) the entire decoded image from memory, already arranged as in the decoded image thanks to operation 640 without need for seeking, rearranging, and / or stitching of block data from numerous blocks from across memory (e.g., from across different portions of DDR memory) . At operation 650, the codec system (or at least one component thereof) is  configured to, and can, call (e.g., by the driver) the processor (e.g., GPU and / or CPU) to perform post-processing of the decoded block. In some examples, post-processing can include alignment adjustment (s) , color space conversion (e.g., YUV to RGB) , and / or application of a deblocking filter. In some examples, use of the GPU can provide a further improvement in efficiency and / or speed for such post-processing operations, for instance because a GPU can typically process more threads in parallel than a CPU. For instance, in some examples, a CPU can process 30 to 40 parallel threads, whereas a GPU can process over 400 parallel threads. Use of the GPU instead of, or in addition to, the CPU for post-processing tasks (e.g., in operation 650) can speed those tasks to be performed ～10 times faster than with the CPU alone, in some illustrative examples.

[0119] The process 600 for batch-wise decoding provides significant improvements in speed and efficiency over the process 300 for block-by-block decoding. In an illustrative example, the total time for the full decoding process for the full image drops from approximately 400 ms (under the process 300) to approximately 150 ms (under the process 600) , a total time decrease of 62.5%. Of this, the hardware decoding (e.g., operation 330, operation 635) remains at 100 ms across both the process 300 and the process 600. The waiting time between two hardware calls (e.g., from one instance of operation 330 to the next instance of operation 330 in the loop 315, or from one instance of operation 635 to the next instance of operation 635 in the loop 620) drops from 200 ms (under the process 300) to 30 ms (under the process 600) . Initializing and finalizing operations drop from 80 ms (under the process 300) to 20 ms (under the process 600) . As noted previously, in an illustrative example, a system decoding 64 MP video frames of a video using the process 300 is only able to achieve a decoding rate of 2.5 video frames per second (fps) . In an illustrative example, the same system decoding 64 MP video frames of a video using the process 600 is only able to achieve a decoding rate of 6.67 video frames per second, a 60%latency reduction.

[0120] FIG. 7 is a conceptual diagram 700 illustrating a batch 705 of blocks in the context of the image 205 of FIG. 2. The batch 705 of blocks includes 38 blocks, specifically including all 19 blocks from the top row of blocks and all 19 blocks from the second-from-top row of blocks. The batch 705 of blocks includes both image data from portions of the image 205 and padding data from portions of the padding (e.g. . the horizontal padding 220) .

[0121] FIG. 8A is a block diagram illustrating a decoding process 800 in which decoded block data is stored in memory 810 in a first arrangement that differs from a second arrangement of the  decoded block data in the image 805. The image 805 illustrated in FIG. 8A is illustrated as the same image as the image 205, with padding (e.g., horizontal padding 220 and / or vertical padding 225) illustrated as included in the image 805 as well. Three exemplary blocks 830 are illustrated in the image 805 of FIG. 8A, labeled as block A, block B, and block C, respectively. Blocks A, B, and C are adjacent to one another in the top row of blocks, starting from the top-left corner of the image 805. Blocks A, B, and C are the first three blocks of the image 805, if the image 805 is viewed block-by-block in a raster scan order. Each of the blocks 830 is illustrated as if each block had only four rows of pixels, even though it should be understood that each block can have more or fewer rows of pixels. For instance, if each of the blocks 830 has dimensions 512×512 pixels as discussed above, then each block can include 512 rows of pixels and 512 columns of pixels. In the decoding process 800, a codec system (e.g., driver, firmware, and / or hardware) decodes the blocks 830 and stores the decoded blocks in the memory 810. In the decoding process 800, a codec system (e.g., driver, firmware, and / or hardware) stores the decoded blocks in the memory 810 according to a first arrangement (e.g., each subsequent pixel being stored in raster order in the memory 810) that differs from a second arrangement of how the block data is stored in the image 805 (e.g., the arrangement of the block data in memory 810 in FIG. 8B) . For instance, in the decoding process 800 (e.g., which may correspond to an example of the process 300) , different rows of pixels from block A can be stored across a portion of a single row of the memory 810, different rows of pixels from block B can be stored across portions of two rows of the memory 810, and different rows of pixels from block C can be stored across a portion of a single row of the memory 810. Thus, rearranging, alignment adjustment, and / or stitching operations (e.g., operation 335) can include rearranging block data from the arrangement of the block data in the memory 810 in FIG. 8A to an arrangement of the block data as in the image 805 and / or the arrangement of the block data in memory 810 in FIG. 8B.

[0122] FIG. 8B is a block diagram illustrating a decoding process 850 in which decoded block data is stored in memory 810 in an arrangement that matches the arrangement of the decoded block data in the image 805. Four exemplary blocks 835 are illustrated in the image 805 of FIG. 8B, labeled as block A, block B, block C, and block Z, respectively. Blocks A, B, and C are adjacent to one another in the top row of blocks in the image 805, starting from the top-left corner of the image 805. Blocks A, B, and C are the first three blocks of the image 805, if the image 805 is  viewed block-by-block in a raster scan order. Block Z is the last block of the image 805, if the image 805 is viewed block-by-block in a raster scan order, and is in the bottom-right corner of the image 805. Each of the blocks 835 is illustrated as if each block had only four rows of pixels, even though it should be understood that each block can have more or fewer rows of pixels. For instance, if each of the blocks 835 has dimensions 512×512 pixels as discussed above, then each block can include 512 rows of pixels and 512 columns of pixels. In the decoding process 850, a codec system (e.g., driver, firmware, and / or hardware) decodes the blocks 835 and stores the decoded blocks in the memory 810. In the decoding process 850, a codec system (e.g., driver, firmware, and / or hardware) stores the decoded blocks in the memory 810 according to an arrangement that matches the arrangement in which the block data is stored in the image 805. For instance, the codec system (e.g., driver, firmware, and / or hardware) can prepare an area of the memory 810 with a width of the area in memory 810 being the horizontal stride 820 of the image 805, and with the height of the area in memory 810 being the vertical stride 825 of the image 805. The block data from block A can be stored in raster scan order of blocks in memory 810 in the same arrangement as in the image 805. For instance, Blocks A, B, and C are stored as the first three blocks in memory 810 (in the top-left corner of the area of memory 810) , if the memory 810 is viewed block-by-block in a block-wise raster scan order. Block Z is the last block of the memory 810 (in the bottom-right corner of the area of memory 810) , if the memory 810 is viewed block-by-block in a block-wise raster scan order. Because the blocks 835 are stored in memory 810 in the same arrangement as in the image 805, once the codec system (e.g., driver, firmware, and / or hardware) stores decoded block data in the area of memory for all of the blocks 835 (blocks A, B, C, and other blocks of the image 805 until block Z) , the area of memory 810 stores the full decoded image. Thus, rearranging, alignment adjustment, and / or stitching operations (e.g., operation 335) can be reduced or prevented entirely in the decoding process 850 (which can correspond to the process 600) .

[0123] FIG. 9A is a chart diagram illustrating time usage 900 by processor (s) performing a decoding process that decodes an image in a block-by-block fashion (e.g., as in the process 300 and / or the decoding process 800) . A horizontal axis represents time 910. Waiting times 920A-920Z (e.g., as in the waiting time curve 525) are illustrated as blocks with dashed borders. Decoding times 925A-925Z (e.g., as in the hardware decoding curve 520) are illustrated as blocks with solid borders. During first waiting time 920A, the driver and / or firmware initializes and  prepares a first encoded block for decoding (e.g., operations 305, 310, 320, and / or 325) . During a first decoding time 925A, the hardware decodes the first encoded block to generate a first decoded block (e.g., operations 330 and / or 335) . During a second waiting time 920B, the driver and / or firmware prepares a second encoded block for decoding (e.g., operations 335, 340, 345, 320, and / or 325) . During a second decoding time 925B, the hardware decodes the second encoded block to generate a second decoded block (e.g., operations 330 and / or 335) . The process continues until a final decoding time 925Z, during which the hardware decodes the final encoded block to generate a final decoded block (e.g., operations 330 and / or 335) , and a final waiting time 920Z, during which the driver and / or firmware and / or processor finalizes image decoding, rearranging, and / or post-processing (e.g., operations 335, 340, and / or 345) .

[0124] FIG. 9B is a chart diagram illustrating time usage 950 by a processor (s) performing a decoding process that decodes an image in batches (e.g., as in the process 600 and / or the decoding process 850) . A horizontal axis represents time 910. Waiting times 930A-930Z are illustrated as blocks with dashed borders. Decoding times 935A-935Z are illustrated as blocks with solid borders. During first waiting time 930A, the driver and / or firmware initializes and prepares a first batch of encoded blocks for decoding (e.g., operations 605, 610, 615, 625, and / or 630) . The first batch of encoded blocks, in the example of FIG. 9B, includes seven blocks. During a first seven decoding times 935A-935G, the hardware decodes the seven encoded blocks of the first batch to generate a first batch of decoded blocks (e.g., operations 635 and / or 640) .

[0125] During a second waiting time 930B, which is performed at least partially in parallel with the first seven decoding times 935A-935G for the first batch of blocks, the driver and / or firmware prepares a second batch of encoded blocks for decoding (e.g., operations 640, 625, and / or 630) . The second batch of encoded blocks, in the example of FIG. 9B, includes seven blocks. During a second batch of seven decoding times 935H-935P, the hardware decodes the second batch of encoded blocks to generate a second batch of decoded blocks (e.g., operations 630 and / or 635) . During a third waiting time 930C, which is performed at least partially in parallel with the first seven decoding times 935H-935P for the second batch of blocks, the driver and / or firmware prepares a third batch of encoded blocks for decoding (e.g., operations 640, 625, and / or 630) .

[0126] The process continues until a final batch of decoding times (e.g., including decoding times 925X-925Z) , and a final waiting time a final waiting time 930Z, during which the driver  and / or firmware and / or processor finalizes image retrieval and / or post-processing (e.g., operations 640, 645, and / or 650) . In some examples, the final waiting time 930Z is performed at least partially in parallel with some of the final batch of decoding times (e.g., in parallel with at least a subset of the decoding times 925X-925Z) .

[0127] The time usage 950 in FIG. 9B (which can correspond to the process 600 and / or the decoding process 850) allows the hardware to run constantly, or nearly constantly (relative to the time usage 900 in FIG. 9A) . This removes many of the times that the hardware sits idle in the time usage 900 of FIG. 9A (which can correspond to the process 300 and / or the decoding process 800) , such as all of the waiting times 920A-920Z. Due to this improvement in efficiency, the process of FIG. 9B can ultimately finish in a shorter amount of time than the process of FIG. 9A.

[0128] FIG. 10A is a chart diagram illustrating time usage 1000 by processor (s) preparing a next block in a decoding process that decodes an image in a block-by-block approach. The time usage 1000 can correspond to the process 300, the decoding process 800, and / or the time usage 900. A horizontal axis represents time 1005. The driver 1010 pushes a first block 1025A to a buffer 1035A (e.g., of a set of one or more buffers 1015) . The driver and / or firmware push the first block 1025A from the buffer 1035A to firmware and / or hardware 1020 for reading and / or decoding operations 1040A. The driver 1010 pushes a second block 1025B to a buffer 1035B (e.g., of a set of one or more buffers 1015) . The driver and / or firmware push the second block 1025B from the buffer 1035B to firmware and / or hardware 1020 for reading and / or decoding operation (s) 1040B. The driver 1010 pushes a third block 1025C to a buffer 1035C (e.g., of a set of one or more buffers 1015) . The driver and / or firmware push the third block 1025C from the buffer 1035C to firmware and / or hardware 1020 for reading and / or decoding operation (s) 1040C. The driver 1010 pushes a fourth block 1025D to a buffer 1035D (e.g., of a set of one or more buffers 1015) . The driver and / or firmware push the fourth block 1025D from the buffer 1035B to firmware and / or hardware 1020 for reading and / or decoding operation (s) 1040D.

[0129] In some examples, the time usage 1000 may include gaps in time (e.g., waiting time, delays) in between adjacent decoding operations (e.g., between decoding operation (s) 1040A and decoding operation (s) 1040B, between decoding operation (s) 1040B and decoding operation (s) 1040C, between decoding operation (s) 1040C and decoding operation (s) 1040D) . These gaps in  time (e.g., delays) can correspond to the waiting times 920A-920Z in the time usage 900 of FIG. 9A.

[0130] FIG. 10B is a chart diagram illustrating time usage 1050 by processor (s) preparing a next batch in a decoding process that decodes an image in a batch-based approach. The time usage 1050 can correspond to the process 600, the decoding process 850, and / or the time usage 950. A horizontal axis represents time 1005. The driver 1010 pushes a first batch 1055A of blocks to a buffer 1060A (e.g., of a set of one or more buffers 1015) . The first batch 1055A of blocks can include for instance, 24 blocks, which are labeled in the buffer 1060A from 1 to 24. The driver and / or firmware push the first batch 1055A of blocks from the buffer 1060A to firmware and / or hardware 1020 for reading and / or decoding operations 1065A. The driver 1010 pushes a second batch 1055B of blocks to a buffer 1060B (e.g., of a set of one or more buffers 1015) . The second batch 1055B of blocks can include for instance, 24 blocks, which are labeled in the buffer 1060B from 25 to 49. The driver and / or firmware push the second batch 1055B of blocks from the buffer 1060B to firmware and / or hardware 1020 for reading and / or decoding operations 1065B.

[0131] The time usage 1050 in FIG. 10B (which can correspond to the process 600, the decoding process 850, and / or the time usage 950) allow more operations to be performed in parallel (relative to the time usage 1000 in FIG. 10A) . This can improve efficiency relative to the time usage 1000 of FIG. 10A (which can correspond to the process 300, the decoding process 800, and / or the time usage 900) , where more operations are performed serially. Due to this improvement in efficiency, the process of FIG. 10B can ultimately finish in a shorter amount of time than the process of FIG. 10A.

[0132] In some examples, the time usage 1050 may lack gaps in time (e.g., waiting time, delays) in between adjacent sets of decoding operations (e.g., between decoding operations 1065A and decoding operations 1065B) . For instance, because at least part of the second batch 1055B of blocks is in the buffer 1060B during some of the decoding operations 1065A, the decoding operations 1065B can start immediately after the decoding operations 1065A (e.g., as in the second waiting time 930B preparing the second batch, the third waiting time 930C preparing the third batch, and so forth) . In some examples, the time usage 1050 may have a small gap in time (e.g., waiting time, delay) in between adjacent sets of decoding operations (e.g., between decoding operations 1065A and decoding operations 1065B) , but the total time spent in such gaps in time  (e.g., waiting time, delays) under the time usage 1050 is still less than the total time spent in such gaps in time (e.g., waiting time, delays) for the time usage 1000. In this way, the time usage 1050 is more efficient (e.g., with less waiting time, delays, and / or gaps in productive time) than the time usage 1000, similarly to how the time usage 950 is more efficient (e.g., with less waiting time, delays, and / or gaps in productive time) than the time usage 900.

[0133] FIG. 11A is a graph diagram illustrating power usage 1100 by processor (s) in a decoding process that decodes an image in a block-by-block fashion. The processor (s) may represent the driver, the firmware, and / or the hardware of a codec system. A vertical axis represents current 1105 (e.g., in milliamps (mA) ) . A horizontal axis represents time 1110. A power draw curve 1120 shows intermittent peaks of high current draw (e.g., corresponding to the decoding of operation 330, the hardware decoding curve 520, and / or the decoding times 925A-925Z) followed by longer lulls of low current draw (e.g., corresponding to waiting time as in the peaks 530 in the waiting time curve 525 and / or the waiting times 920A-920Z) .

[0134] FIG. 11B is a graph diagram illustrating power usage 1150 by processor (s) in a decoding process that decodes an image in batches. The processor (s) may represent the driver, the firmware, and / or the hardware of a codec system. A vertical axis represents current 1105 (e.g., in milliamps (mA) ) . A horizontal axis represents time 1110. A power draw curve 1125 shows sustained plateaus of high current draw (e.g., corresponding to the decoding of operation 635 and / or the decoding times 935A-935Z) punctuated by intermittent dips (e.g., corresponding to waiting times 930A-930Z) .

[0135] The power usage 1150 in FIG. 11B (which can correspond to the process 600, the decoding process 850, the time usage 950, and / or the time usage 1050) puts the codec system (e.g., the driver, the firmware, and / or the hardware) to more efficient use (relative to the time usage 1000 in FIG. 10A) . This can result in a decrease in total power usage relative to the power usage 1100 of FIG. 11A (which can correspond to the process 300, the decoding process 800, the time usage 900, and / or the time usage 1000) , where the codec system is used less efficiently due to increased waiting time. Due to this improvement in efficiency, the process of FIG. 11B can ultimately finish in a shorter amount of time than the process of FIG. 11A, and can use less total power than the process of FIG. 11A.

[0136] FIG. 12 is a flow diagram illustrating a process 1200. The codec process 1200 may be performed by a codec system. In some examples, the codec system can include, for example, a codec, an encoder, the video source 102, the encoding device 104, the encoding engine 106, the storage 108, the output 110, the communications link 120, a decoder, the decoding device 112, the input 114, the decoder engine 116, the storage 118, the video destination device 122, the decoding device 112, the decoder engine 116, an encoder, the encoding device 104, the encoder engine 106, the codec system that performs the process 300, the codec system that performs the process 600, the memory 810, the processor (s) of FIGs. 9A-9B, the processor (s) of FIGs. 10A-10B, the processor (s) of FIGs. 9A-9B, the processor (s) of FIGs. 10A-10B, the driver 1010, the buffer 1015, the firmware and / or hardware 1020, the processor (s) of FIGs. 11A-11B, the processor (s) of FIGs. 11A-11B, the computing system 1300, the processor 1310, an apparatus, a non-transitory computer-readable medium that stores instructions for execution by one or more processors, a mobile handset, an HMD, a wireless communication device, a CPU, a GPU, an APU, an ASIC, an FPGA, or a combination thereof.

[0137] At operation 1205, the codec system (or at least one component thereof) is configured to, and can, decode a batch of encoded blocks to generate decoded block data. The batch of encoded blocks includes a plurality of encoded blocks from an encoded image. Examples of the encoded image include the output 110 of the encoding device 104, the input 114 of the decoding device 112, an encoded version of the image 205 (e.g., encoded with the padding 220 and / or the padding 225, or encoded without the padding 220 and / or the padding 225) , encoded image data in the decoding queue of operations 305-310, encoded image data that includes blocks 410A-410H, encoded image data being decoded according to the graph diagram 500, encoded image data in the decoding queue of operations 605-615, the image 805, encoded image data to be decoded during the decoding times 925A-925Z of FIG. 9A and / or FIG. 9B, encoded image data that includes the blocks 1025A-1025D, encoded image data that includes the blocks in the first batch 1055A, encoded image data that includes the blocks in the second batch 1055B, encoded image data to be decoded according to the power draw curve 1120, encoded image data to be decoded according to the power draw curve 1125, or a combination thereof. Examples of the encoded blocks include blocks of the output 110 of the encoding device 104, blocks of the input 114 of the decoding device 112, the blocks of the image 205, the blocks received in operation 310, the block of the loop 315,  the blocks 410A-410H, the blocks having any of the block numbers 510, a block in the batch of the loop 620, the blocks in the batch 705, the blocks 830, the blocks 835, blocks to be decoded during the decoding times 925A-925Z of FIG. 9A and / or FIG. 9B, the blocks 1025A-1025D, the blocks in the first batch 1055A, the blocks in the second batch 1055B, blocks to be decoded according to the power draw curve 1120, blocks to be decoded according to the power draw curve 1125, or a combination thereof. Examples of the batch include the batch of operations 605-615 and / or of the loop 620, the batch 705, a batch of the blocks 830, a batch of the blocks 835, the batch of blocks prepared during first waiting time 930A and decoded during decoding times 925A-925G of FIG. 9B, the batch of blocks prepared during second waiting time 930B and decoded during decoding times 925H-925P of FIG. 9B, the batch of blocks prepared during third waiting time 930C of FIG. 9B, the batch of blocks decoded during decoding times 925X-925Z of FIG. 9B, the first batch 1055A, the second batch 1055B, the batches of blocks decoded according to the power draw curve 1125, or a combination thereof.

[0138] Examples of the decoded block data include blocks of an output of the decoding device 112 and / or the decoder engine 116, blocks of an image received and / or output by the video destination device 122, blocks of a decoded version of the image 205 (e.g., without the padding horizontal padding 220 and / or the padding vertical padding 225) , decoded blocks generated and / or manipulated in operations 330-345 of the loop 315, decoded variants of the blocks 410A-410H, blocks decoded in the decoding process illustrated in the graph diagram 500, blocks decoded back-wise in operations 635-640 of the loop 620, blocks of the whole image of operation 645, decoded variants of the blocks 830 stored in the memory 810, decoded variants of the blocks 835 stored in the memory 810, blocks decoded during the decoding times 925A-925Z of FIG. 9A and / or FIG. 9B, blocks decoded using decoding operations 1040A-1040D, blocks decoded using decoding operations 1065A-1065D, blocks decoded according to the power draw curve 1120, blocks decoded according to the power draw curve 1125, or a combination thereof.

[0139] In some examples, the codec system (or at least one component thereof) is configured to, and can, receive the plurality of encoded blocks from an encoder, the encoder having encoded an image to generate the plurality of encoded blocks. Examples of the encoder include the encoding device 104, the encoder engine 106, another encoder discussed herein, or a combination thereof.  In some examples, the codec system includes the encoder. In some examples the codec system includes a decoder. In some examples, the codec system does not include the encoder.

[0140] In some examples, the codec system (or at least one component thereof) is configured to, and can, receive the encoded image via a bitstream.

[0141] At operation 1210, the codec system (or at least one component thereof) is configured to, and can, store the decoded block data in an area of memory. A size of the area of the memory is based on a stride associated with the encoded image. An arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image (e.g., the arrangement of decoded block data in the area of the memory 810 illustrated in FIG. 8B is based on the arrangement of the blocks 835 in the image 805) .

[0142] Examples of the memory include the storage 108, the storage 118, memory associated with the firmware and / or the driver of the loop 315, the memory in which the arrangement 400 of blocks is stored, the memory in which the arrangement 450 of blocks is stored, the stride-aligned area of memory of operation 640, the memory 810, the cache 1312, the system memory 1315, the ROM 1320, the RAM 1325, the storage device 1330, or a combination thereof. Examples of the area of the memory include an area in the storage 108, an area in the storage 118, an area in memory associated with the firmware and / or the driver of the loop 315, an area in the memory in which the arrangement 400 of blocks is stored, an area in the memory in which the arrangement 450 of blocks is stored, the stride-aligned area of memory of operation 640, the area of the memory 810 that is illustrated in FIG. 8A and / or FIG. 8B, an area of the cache 1312, an area of the system memory 1315, an area of the ROM 1320, an area of the RAM 1325, an area of the storage device 1330, or a combination thereof. Examples of the size of the area of the memory include the dimensions of the memory 810 of FIG. 8B (e.g., a width of the area of the memory 810 matching the horizontal stride 820 and a height of the area of the memory 810 matching the vertical stride 825) a size of any of the examples of the area of memory listed above, or a combination thereof. Examples of the stride associated with the encoded image include the horizontal stride 230, the vertical stride 235, the stride in the image information of operation 615, the horizontal stride 820, the vertical stride 825, or a combination thereof.

[0143] Examples of the arrangement of the decoded block data in the area of the memory include the arrangement 400, the arrangement 450, an arrangement of the batch of the loop 620 in the stride-aligned area of memory of operation 640, an arrangement of the decoded block data in the stride-aligned area of memory that is retrieved as the whole image in operation 645, the arrangement of the block data from decoding the blocks 830 in the illustrated area of the memory 810 in FIG. 8A, the arrangement of the block data from decoding the blocks 835 in the illustrated area of the memory 810 (e.g., with the width of the area of the memory 810 matching the horizontal stride 820 and the height of the area of the memory 810 matching the vertical stride 825) in FIG. 8B, or a combination thereof. Examples of the arrangement of the batch of encoded blocks in the encoded image include the arrangement of the blocks in the image 205, arrangement 450, an arrangement of the batch of blocks of operation 610 and / or of the loop 620, an arrangement of batch 705 in the image 205, an arrangement of the blocks 830 in the image 805, an arrangement of the blocks 835 in the image 805, or a combination thereof.

[0144] At operation 1215, the codec system (or at least one component thereof) is configured to, and can, output a decoded image based on the arrangement of the decoded block data in the area of the memory. Examples of the decoded image include an output of the decoding device 112 and / or the decoder engine 116, an image received and / or output by the video destination device 122, a decoded version of the image 205 (e.g., without the padding horizontal padding 220 and / or the padding vertical padding 225) , an output of the process 300 (e.g., the full image of operation 345) , an output of the decoding process illustrated in the graph diagram 500, an output of the process 600 (e.g., the whole image of operation 645 before or after the post-processing of operation 650) , a decoded image based on the decoded image data stored in the memory 810 in FIG. 8A and / or FIG. 8B, an image decoded during the decoding times 925A-925Z of FIG. 9A and / or FIG. 9B, an image decoded using decoding operations 1040A-1040D, an image decoded using decoding operations 1065A-1065D, or a combination thereof.

[0145] In some examples, the codec system (or at least one component thereof) is configured to, and can, process the decoded image after operation 1210 (and before operation 1215, after operation 1215, and / or during operation 1215) . Examples of the processing can include operation 340, operation 345, operation 650, or a combination thereof. In some aspects, processing the decoded image is performed using a graphics processing unit (GPU, a central processing unit  (CPU) , an APU, an ASIC, an FPGA, another type of processor discussed herein, or a combination thereof. In some examples, processing the decoded image includes applying an alignment adjustment to the decoded image, converting the decoded image from a first color space to a second color space (e.g., between YUV and RGB) , applying a deblocking filter to the decoded image, another post-processing operation discussed herein (e.g., with regard to operation 340 or operation 650 or otherwise) , or a combination thereof.

[0146] In some aspects, a length of the area of the memory matches the stride associated with the encoded image. The length can refer to any side of the area of the memory, such as a width or height. For instance, the width of the memory 810 matches the horizontal stride 820 of the image 805, and the heigh of the memory 810 matches the vertical stride 825 of the image 805.

[0147] In some examples, the codec system (or at least one component thereof) is configured to, and can, prepare a second batch of encoded blocks for decoding in parallel with decoding the batch of encoded blocks. For instance, the codec system can prepare a second batch while decoding a first batch, as in the second waiting time 930B during the decoding times 925A-925G of FIG. 9B, or the storage of the second batch 1055B into the buffer 1060B during the decoding operations 1065A. The codec system can decode the second batch of encoded blocks to generate secondary decoded block data. The codec system can store the secondary decoded block data in the area of memory. An arrangement of the secondary decoded block data in the area of the memory is based on an arrangement of the second batch of encoded blocks in the encoded image. The decoded image is based on the arrangement of the secondary decoded block data in the area of the memory.

[0148] In some aspects, an arrangement of the decoded block data in the decoded image matches the arrangement of the decoded block data in the area of the memory (e.g., the arrangement of decoded block data in the area of the memory 810 illustrated in FIG. 8B matches the arrangement of the blocks 835 in the image 805) .

[0149] In some aspects, the memory stores instructions to be executed by at least one processor, and at least a subset of the process 1200 is performed using the at least one processor in response to the at least one processor executing the instructions. In some aspects, a second memory stores instructions to be executed by at least one processor, and the memory is distinct from the second memory, and at least a subset of the process 1200 is performed using the at least one processor in  response to the at least one processor executing the instructions. In some aspects, the area of the memory is part of a Double Data Rate (DDR) memory. In some aspects, the memory is the DDR memory.

[0150] In some aspects, storing the decoded block data in the area of memory (as in operation 1210) includes storing the decoded block data in the area of memory in raster scan order per decoded block corresponding to the batch of encoded blocks. For instance, the decoded block data from decoding the blocks 835 in FIG. 8B can be stored in the area of the memory 810 illustrated in FIG. 8B block-by-block in raster scan order of blocks. In some aspects, storing the decoded block data in the area of memory (as in operation 1210) includes storing the decoded block data in the area of memory in raster scan order across a batch of decoded blocks corresponding to the batch of encoded blocks. For instance, a batch of decoded block data from decoding a batch of the blocks 835 in FIG. 8B can be stored in the area of the memory 810 illustrated in FIG. 8B batch-by-batch in raster scan order of batches of blocks.

[0151] In some aspects, the encoded image is a video frame of an encoded video, and the decoded image is a video frame of a decoded video corresponding to the encoded video.

[0152] In some examples, the codec system (or at least one component thereof) includes at least one of a head-mounted display (HMD) , a mobile handset, or a wireless communication device.

[0153] In some examples, the processes described herein (e.g., the respective processes of FIGs. 1, 2, 3, 4A-4B, 5, 6, 7, 8A-8B, 9A-9B, 10A-10B, 11A-11B, the codec process 1200 of FIG. 12, and / or other processes described herein) may be performed by a computing device or apparatus. In some examples, the processes described herein can be performed by, and / or using, the video source 102, the encoding device 104, the encoding engine 106, the storage 108, the output 110, the communications link 120, a decoder, the decoding device 112, the input 114, the decoder engine 116, the storage 118, the video destination device 122, the decoding device 112, the decoder engine 116, an encoder, the encoding device 104, the encoder engine 106, the codec system that performs the process 300, the codec system that performs the process 600, the memory 810, the processor (s) of FIGs. 9A-9B, the processor (s) of FIGs. 10A-10B, the driver 1010, the buffer 1015, the firmware and / or hardware 1020, the processor (s) of FIGs. 11A-11B, the codec system that performs the process 1200, the computing system 1300, the processor 1310, an apparatus, a non- transitory computer-readable medium that stores instructions for execution by one or more processors, a mobile handset, an HMD, a wireless communication device, a CPU, a GPU, an APU, an ASIC, an FPGA, or a combination thereof.

[0154] The computing device can include any suitable device, such as a mobile device (e.g., a mobile phone) , a desktop computing device, a tablet computing device, a wearable device (e.g., a VR headset, an AR headset, AR glasses, a network-connected watch or smartwatch, or other wearable device) , a server computer, an autonomous vehicle or computing device of an autonomous vehicle, a robotic device, a television, and / or any other computing device with the resource capabilities to perform the processes described herein. In some cases, the computing device or apparatus may include various components, such as one or more input devices, one or more output devices, one or more processors, one or more microprocessors, one or more microcomputers, one or more cameras, one or more sensors, and / or other component (s) that are configured to carry out the steps of processes described herein. In some examples, the computing device may include a display, a network interface configured to communicate and / or receive the data, any combination thereof, and / or other component (s) . The network interface may be configured to communicate and / or receive Internet Protocol (IP) based data or other type of data.

[0155] The components of the computing device can be implemented in circuitry. For example, the components can include and / or can be implemented using electronic circuits or other electronic hardware, which can 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 circuits) , and / or can include and / or be implemented using computer software, firmware, or any combination thereof, to perform the various operations described herein.

[0156] The processes described herein are illustrated as logical flow diagrams, block diagrams, or conceptual diagrams, the operation of which represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement  particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the processes. In some examples, performance of certain operations described herein can be responsive to performance of other operations described herein.

[0157] Additionally, the processes described herein may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer-readable or machine-readable storage medium, for example, 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 may be non-transitory.

[0158] FIG. 13 is a diagram illustrating an example of a system for implementing certain aspects of the present technology. In particular, FIG. 13 illustrates an example of computing system 1300, which can be for example any computing device making up internal computing system, a remote computing system, a camera, or any component thereof in which the components of the system are in communication with each other using connection 1305. Connection 1305 can be a physical connection using a bus, or a direct connection into processor 1310, such as in a chipset architecture. Connection 1305 can also be a virtual connection, networked connection, or logical connection.

[0159] In some aspects, computing system 1300 is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple data centers, a peer network, etc. In some aspects, one or more of the described system components represents many such components each performing some or all of the function for which the component is described. In some aspects, the components can be physical or virtual devices.

[0160] Example system 1300 includes at least one processing unit (CPU or processor) 1310 and connection 1305 that couples various system components including system memory 1315, such as read-only memory (ROM) 1320 and random access memory (RAM) 1325 to processor 1310. Computing system 1300 can include a cache 1312 of high-speed memory connected directly with, in close proximity to, or integrated as part of processor 1310.

[0161] Processor 1310 can include any general purpose processor and a hardware service or software service, such as services 1332, 1334, and 1336 stored in storage device 1330, configured to control processor 1310 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor 1310 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

[0162] To enable user interaction, computing system 1300 includes an input device 1345, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system 1300 can also include output device 1335, which can be one or more of a number of output mechanisms. In some instances, multimodal systems can enable a user to provide multiple types of input / output to communicate with computing system 1300. Computing system 1300 can include communications interface 1340, which can generally govern and manage the user input and system output. The communication interface may perform or facilitate receipt and / or transmission wired or wireless communications using wired and / or wireless transceivers, including those making use of an audio jack / plug, a microphone jack / plug, a universal serial bus (USB) port / plug, an port / plug, an Ethernet port / plug, a fiber optic port / plug, a proprietary wired port / plug, a wireless signal transfer, a low energy (BLE) wireless signal transfer, an wireless signal transfer, a radio-frequency identification (RFID) wireless signal transfer, near-field communications (NFC) wireless signal transfer, dedicated short range communication (DSRC) wireless signal transfer, 1302.11 Wi-Fi wireless signal transfer, wireless local area network (WLAN) signal transfer, Visible Light Communication (VLC) , Worldwide Interoperability for Microwave Access (WiMAX) , Infrared (IR) communication wireless signal transfer, Public Switched Telephone Network (PSTN) signal transfer, Integrated Services Digital Network (ISDN) signal transfer, 3G / 4G / 5G / LTE cellular data network wireless signal transfer, ad-hoc network signal transfer, radio wave signal transfer, microwave signal transfer, infrared signal transfer, visible light signal transfer, ultraviolet light signal transfer, wireless signal transfer along the electromagnetic spectrum, or some combination thereof. The communications interface 1340 may also include one or more Global Navigation Satellite System (GNSS) receivers or transceivers that are used to determine a location of the computing system 1300 based on receipt of one or more  signals from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US-based Global Positioning System (GPS) , the Russia-based Global Navigation Satellite System (GLONASS) , the China-based BeiDou Navigation Satellite System (BDS) , and the Europe-based Galileo GNSS. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0163] Storage device 1330 can be a non-volatile and / or non-transitory and / or computer-readable memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, a floppy disk, a flexible disk, a hard disk, magnetic tape, a magnetic strip / stripe, any other magnetic storage medium, flash memory, memristor memory, any other solid-state memory, a compact disc read only memory (CD-ROM) optical disc, a rewritable compact disc (CD) optical disc, digital video disk (DVD) optical disc, a blu-ray disc (BDD) optical disc, a holographic optical disk, another optical medium, a secure digital (SD) card, a micro secure digital (microSD) card, a Memory card, a smartcard chip, a EMV chip, a subscriber identity module (SIM) card, a mini / micro / nano / pico SIM card, another integrated circuit (IC) chip / card, random access memory (RAM) , static RAM (SRAM) , dynamic RAM (DRAM) , read-only memory (ROM) , programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , flash EPROM (FLASHEPROM) , cache memory (L1 / L2 / L3 / L4 / L5 / L#) , resistive random-access memory (RRAM / ReRAM) , phase change memory (PCM) , spin transfer torque RAM (STT-RAM) , another memory chip or cartridge, and / or a combination thereof.

[0164] The storage device 1330 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 1310, it causes the system to perform a function. In some aspects, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 1310, connection 1305, output device 1335, etc., to carry out the function.

[0165] As used herein, the term “computer-readable medium” includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other mediums  capable of storing, containing, or carrying instruction (s) and / or data. A computer-readable medium may include a non-transitory medium in which data can be stored and that does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections. Examples of a non-transitory medium may include, but are not limited to, a magnetic disk or tape, optical storage media such as compact disk (CD) or digital versatile disk (DVD) , flash memory, memory or memory devices. A computer-readable medium may have stored thereon code and / or machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, or the like.

[0166] In some aspects, the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0167] Specific details are provided in the description above to provide a thorough understanding of the aspects and examples provided herein. However, it will be understood by one of ordinary skill in the art that the aspects may be practiced without these specific details. For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software. Additional components may be used other than those shown in the figures and / or described herein. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the aspects in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the aspects.

[0168] Individual aspects may be described above as a process or method which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram.  Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0169] Processes and methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer-readable media. Such instructions can include, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or a processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, source code, etc. Examples of computer-readable media that may be used to store instructions, information used, and / or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

[0170] Devices implementing processes and methods according to these disclosures can include hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and can take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks (e.g., a computer-program product) may be stored in a computer-readable or machine-readable medium. A processor (s) may perform the necessary tasks. Typical examples of form factors include laptops, smart phones, mobile phones, tablet devices or other small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

[0171] The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are example means for providing the functions described in the disclosure.

[0172] In the foregoing description, aspects of the application are described with reference to specific aspects thereof, but those skilled in the art will recognize that the application is not limited thereto. Thus, while illustrative aspects of the application have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art. Various features and aspects of the above-described application may be used individually or jointly. Further, aspects can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive. For the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate aspects, the methods may be performed in a different order than that described.

[0173] One of ordinary skill will appreciate that the less than ( “<” ) and greater than ( “>” ) symbols or terminology used herein can be replaced with less than or equal to ( “≤” ) and greater than or equal to ( “≥” ) symbols, respectively, without departing from the scope of this description.

[0174] Where components are described as being “configured to” perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits or other hardware to perform the operation, by programming programmable electronic circuits (e.g., microprocessors, or other suitable electronic circuits) to perform the operation, or any combination thereof.

[0175] The phrase “coupled to” refers to any component that is physically connected to another component either directly or indirectly, and / or any component that is in communication with another component (e.g., connected to the other component over a wired or wireless connection, and / or other suitable communication interface) either directly or indirectly.

[0176] Claim language or other language reciting “at least one of” a set and / or “one or more” of a set indicates that one member of the set or multiple members of the set (in any combination)  satisfy the claim. For example, claim language reciting “at least one of A and B” means A, B, or A and B. In another example, claim language reciting “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 language “at least one of” a set and / or “one or more” of a set does not limit the set to the items listed in the set. For example, claim language reciting “at least one of A and B” can mean A, B, or A and B, and can additionally include items not listed in the set of A and B.

[0177] The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, firmware, or combinations thereof. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0178] The techniques described herein may also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques may be implemented in any of a variety of devices such as general purposes computers, wireless communication device handsets, or integrated circuit devices having multiple uses including application in wireless communication device handsets and other devices. Any features described as modules or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized at least in part by a computer-readable data storage medium comprising program code including instructions that, when executed, performs one or more of the methods described above. The computer-readable data storage medium may form part of a computer program product, which may include packaging materials. The computer-readable medium may comprise memory or data storage media, such as random access memory (RAM) such as synchronous dynamic random access memory (SDRAM) , read-only memory (ROM) , non-volatile random access memory (NVRAM) , electrically erasable programmable read-only memory (EEPROM) , FLASH memory, magnetic or optical data storage media, and the like. The techniques additionally, or alternatively,  may be realized at least in part by a computer-readable communication medium that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer, such as propagated signals or waves.

[0179] The program code may be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs) , general purpose microprocessors, an application specific integrated circuits (ASICs) , field programmable logic arrays (FPGAs) , or other equivalent integrated or discrete logic circuitry. Such a processor may be configured to perform any of the techniques described in this disclosure. A general purpose processor may be a microprocessor; but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Accordingly, the term “processor, ” as used herein may refer to any of the foregoing structure, any combination of the foregoing structure, or any other structure or apparatus suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated software modules or hardware modules configured for encoding and decoding, or incorporated in a combined video encoder-decoder (CODEC) .

[0180] Illustrative aspects of the disclosure include:

[0181] Aspect 1: An apparatus for decoding, the apparatus comprising: a memory; and one or more processors coupled to the memory, the one or more processors configured to: decode a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image; store the decoded block data in an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; and output a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0182] Aspect 2. The apparatus of Aspect 1, wherein the at least one processor is configured to: process the decoded image.

[0183] Aspect 3. The apparatus of Aspect 2, wherein the at least one processor includes a graphics processing unit (GPU) , and wherein, to process the decoded image, the at least one processor is configured to use the GPU to process the decoded image.

[0184] Aspect 4. The apparatus of any one of Aspects 2 to 3, wherein, to process the decoded image, the at least one processor is configured to apply an alignment adjustment to the decoded image.

[0185] Aspect 5. The apparatus of any one of Aspects 2 to 4, wherein, to process the decoded image, the at least one processor is configured to convert the decoded image from a first color space to a second color space.

[0186] Aspect 6. The apparatus of any one of Aspects 2 to 5, wherein, to process the decoded image, the at least one processor is configured to apply a deblocking filter to the decoded image.

[0187] Aspect 7. The apparatus of any one of Aspects 1 to 6, wherein a length of the area of the memory matches the stride associated with the encoded image.

[0188] Aspect 8. The apparatus of any one of Aspects 1 to 7, wherein the at least one processor is configured to: prepare a second batch of encoded blocks for decoding in parallel with decoding the batch of encoded blocks; decode the second batch of encoded blocks to generate secondary decoded block data; and store the secondary decoded block data in the area of memory, wherein an arrangement of the secondary decoded block data in the area of the memory is based on an arrangement of the second batch of encoded blocks in the encoded image, and wherein the decoded image is based on the arrangement of the secondary decoded block data in the area of the memory.

[0189] Aspect 9. The apparatus of any one of Aspects 1 to 8, further comprising: an encoder that encodes an image to generate the plurality of encoded blocks.

[0190] Aspect 10. The apparatus of any one of Aspects 1 to 9, wherein an arrangement of the decoded block data in the decoded image matches the arrangement of the decoded block data in the area of the memory.

[0191] Aspect 11. The apparatus of any one of Aspects 1 to 10, wherein the area of the memory is part of the at least one memory.

[0192] Aspect 12. The apparatus of any one of Aspects 1 to 11, wherein the area of the memory is part of a second memory that is distinct from the at least one memory.

[0193] Aspect 13. The apparatus of any one of Aspects 1 to 12, wherein the area of the memory is part of a Double Data Rate (DDR) memory.

[0194] Aspect 14. The apparatus of any one of Aspects 1 to 13, wherein, to store the decoded block data in the area of memory, the at least one processor is configured to store the decoded block data in the area of memory in raster scan order per decoded block corresponding to the batch of encoded blocks.

[0195] Aspect 15. The apparatus of any one of Aspects 1 to 14, wherein, to store the decoded block data in the area of memory, the at least one processor is configured to store the decoded block data in the area of memory in raster scan order across a batch of decoded blocks corresponding to the batch of encoded blocks.

[0196] Aspect 16. The apparatus of any one of Aspects 1 to 15, wherein the at least one processor is configured to: receive the encoded image via a bitstream.

[0197] Aspect 17. The apparatus of any one of Aspects 1 to 16, wherein the encoded image is a video frame of an encoded video, and wherein the decoded image is a video frame of a decoded video corresponding to the encoded video.

[0198] Aspect 18. A method for decoding, the method comprising: decoding a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image; storing the decoded block data in an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; and outputting a decoded image based on the arrangement of the decoded block data in the area of the memory.

[0199] Aspect 19. The method of Aspect 18, further comprising: processing the decoded image.

[0200] Aspect 20. The method of Aspect 19, wherein processing the decoded image includes using a graphics processing unit (GPU) to process the decoded image.

[0201] Aspect 21. The method of any one of Aspects 19 to 20, wherein processing the decoded image includes applying an alignment adjustment to the decoded image.

[0202] Aspect 22. The method of any one of Aspects 19 to 21, wherein processing the decoded image includes converting the decoded image from a first color space to a second color space.

[0203] Aspect 23. The method of any one of Aspects 19 to 22, wherein processing the decoded image includes applying a deblocking filter to the decoded image.

[0204] Aspect 24. The method of any one of Aspects 18 to 23, wherein a length of the area of the memory matches the stride associated with the encoded image.

[0205] Aspect 25. The method of any one of Aspects 18 to 24, further comprising: preparing a second batch of encoded blocks for decoding in parallel with decoding the batch of encoded blocks; decoding the second batch of encoded blocks to generate secondary decoded block data; and storing the secondary decoded block data in the area of memory, wherein an arrangement of the secondary decoded block data in the area of the memory is based on an arrangement of the second batch of encoded blocks in the encoded image, and wherein the decoded image is based on the arrangement of the secondary decoded block data in the area of the memory.

[0206] Aspect 26. The method of any one of Aspects 18 to 25, further comprising: receiving the plurality of encoded blocks from an encoder, the encoder having encoded an image to generate the plurality of encoded blocks.

[0207] Aspect 27. The method of any one of Aspects 18 to 26, wherein an arrangement of the decoded block data in the decoded image matches the arrangement of the decoded block data in the area of the memory.

[0208] Aspect 28. The method of any one of Aspects 18 to 27, wherein the memory stores instructions to be executed by at least one processor, wherein decoding the batch includes decoding the batch using the at least one processor in response to the at least one processor executing the instructions.

[0209] Aspect 29. The method of any one of Aspects 18 to 28, wherein a second memory stores instructions to be executed by at least one processor, wherein the memory is distinct from the  second memory, and wherein decoding the batch includes decoding the batch using the at least one processor in response to the at least one processor executing the instructions.

[0210] Aspect 30. The method of any one of Aspects 18 to 29, wherein the area of the memory is part of a Double Data Rate (DDR) memory.

[0211] Aspect 31. The method of any one of Aspects 18 to 30, wherein storing the decoded block data in the area of memory includes storing the decoded block data in the area of memory in raster scan order per decoded block corresponding to the batch of encoded blocks.

[0212] Aspect 32. The method of any one of Aspects 18 to 31, wherein storing the decoded block data in the area of memory includes storing the decoded block data in the area of memory in raster scan order across a batch of decoded blocks corresponding to the batch of encoded blocks.

[0213] Aspect 33. The method of any one of Aspects 18 to 32, further comprising: receive the encoded image via a bitstream.

[0214] Aspect 34. The method of any one of Aspects 18 to 33, wherein the encoded image is a video frame of an encoded video, and wherein the decoded image is a video frame of a decoded video corresponding to the encoded video.

[0215] Aspect 35. A non-transitory computer-readable medium having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to perform operations according to any of Aspects 1 to 34.

[0216] Aspect 36. An apparatus for imaging, the apparatus comprising one or more means for performing operations according to any of Aspects 1 to 34.

Claims

1.An apparatus for decoding, the apparatus comprising:at least one memory configured; andat least one processor coupled to the at least one memory, the at least one processor configured to:decode a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image;store the decoded block data in an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; andoutput a decoded image based on the arrangement of the decoded block data in the area of the memory.2.The apparatus of claim 1, wherein the at least one processor is configured to:process the decoded image.3.The apparatus of claim 2, wherein the at least one processor includes a graphics processing unit (GPU) , and wherein, to process the decoded image, the at least one processor is configured to use the GPU to process the decoded image.4.The apparatus of claim 2, wherein, to process the decoded image, the at least one processor is configured to apply an alignment adjustment to the decoded image.5.The apparatus of claim 2, wherein, to process the decoded image, the at least one processor is configured to convert the decoded image from a first color space to a second color space.6.The apparatus of claim 2, wherein, to process the decoded image, the at least one processor is configured to apply a deblocking filter to the decoded image.7.The apparatus of claim 1, wherein a length of the area of the memory matches the stride associated with the encoded image.8.The apparatus of claim 1, wherein the at least one processor is configured to:prepare a second batch of encoded blocks for decoding in parallel with decoding the batch of encoded blocks;decode the second batch of encoded blocks to generate secondary decoded block data; andstore the secondary decoded block data in the area of memory, wherein an arrangement of the secondary decoded block data in the area of the memory is based on an arrangement of the second batch of encoded blocks in the encoded image, and wherein the decoded image is based on the arrangement of the secondary decoded block data in the area of the memory.9.The apparatus of claim 1, further comprising:an encoder that encodes an image to generate the plurality of encoded blocks.10.The apparatus of claim 1, wherein an arrangement of the decoded block data in the decoded image matches the arrangement of the decoded block data in the area of the memory.11.The apparatus of claim 1, wherein the area of the memory is part of the at least one memory.12.The apparatus of claim 1, wherein the area of the memory is part of a second memory that is distinct from the at least one memory.13.The apparatus of claim 1, wherein the area of the memory is part of a Double Data Rate (DDR) memory.14.The apparatus of claim 1, wherein, to store the decoded block data in the area of memory, the at least one processor is configured to store the decoded block data in the area of memory in raster scan order per decoded block corresponding to the batch of encoded blocks.15.The apparatus of claim 1, wherein, to store the decoded block data in the area of memory, the at least one processor is configured to store the decoded block data in the area of memory in raster scan order across a batch of decoded blocks corresponding to the batch of encoded blocks.16.The apparatus of claim 1, wherein the at least one processor is configured to:receive the encoded image via a bitstream.17.The apparatus of claim 1, wherein the encoded image is a video frame of an encoded video, and wherein the decoded image is a video frame of a decoded video corresponding to the encoded video.18.A method for decoding, the method comprising:decoding a batch of encoded blocks to generate decoded block data, wherein the batch of encoded blocks includes a plurality of encoded blocks from an encoded image;storing the decoded block data in an area of memory, wherein a size of the area of the memory is based on a stride associated with the encoded image, wherein an arrangement of the decoded block data in the area of the memory is based on an arrangement of the batch of encoded blocks in the encoded image; andoutputting a decoded image based on the arrangement of the decoded block data in the area of the memory.19.The method of claim 18, further comprising:processing the decoded image.20.The method of claim 18, further comprising:preparing a second batch of encoded blocks for decoding in parallel with decoding the batch of encoded blocks;decoding the second batch of encoded blocks to generate secondary decoded block data; andstoring the secondary decoded block data in the area of memory, wherein an arrangement of the secondary decoded block data in the area of the memory is based on an arrangement of the second batch of encoded blocks in the encoded image, and wherein the decoded image is based on the arrangement of the secondary decoded block data in the area of the memory.

Images