Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
  • H04N19/136—Incoming video signal characteristics or properties
  • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
  • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
  • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
  • H04N19/51—Motion estimation or motion compensation
  • H04N19/513—Processing of motion vectors
  • H04N19/521—Processing of motion vectors for estimating the reliability of the determined motion vectors or motion vector field, e.g. for smoothing the motion vector field or for correcting motion vectors
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
  • H04N19/136—Incoming video signal characteristics or properties
  • H04N19/14—Coding unit complexity, e.g. amount of activity or edge presence estimation
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
  • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
  • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
  • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
  • H04N19/182—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a pixel
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/46—Embedding additional information in the video signal during the compression process
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
  • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
  • H04N19/51—Motion estimation or motion compensation
  • H04N19/513—Processing of motion vectors
  • H04N19/517—Processing of motion vectors by encoding
  • H04N19/52—Processing of motion vectors by encoding by predictive encoding

Definitions

• the present principles generally relate to a method and an apparatus for video encoding and decoding, and more particularly, to a method and an apparatus for video encoding and decoding with motion information refinement.
• image and video coding schemes usually employ prediction and transform to leverage spatial and temporal redundancy in the video content.
• intra or inter prediction is used to exploit the intra or inter frame correlation, then the differences between the original image and the predicted image, often denoted as prediction errors or prediction residuals, are transformed, quantized, and entropy coded.
• the compressed data is decoded by inverse processes corresponding to the prediction, transform, quantization, and entropy coding.
• a method for video decoding comprising: accessing an initial motion vector predictor for a current block of a video, the initial motion vector predictor being associated with a first motion resolution; determining whether or not to refine the initial motion vector predictor, based on a motion vector difference; and if the initial motion vector predictor is determined to be refined, refining the initial motion vector predictor based on motion search to form a refined motion vector predictor and decoding the current block based on the refined motion vector predictor, the refined motion vector predictor being associated with a second motion resolution, and the second motion resolution being higher than the first motion resolution.
• the initial motion vector predictor When a magnitude of the motion vector difference is smaller than a first threshold, the initial motion vector predictor may be determined to be refined. When a magnitude of the motion vector difference exceeds a second threshold, the initial motion vector predictor may be determined not to be refined, and the current block is decoded based on the initial motion vector predictor.
• the activation or deactivation of motion refinement is automatically performed, without explicit signaling.
• a flag may be decoded from a bitstream, and whether or not the initial motion vector predictor is to be refined is based on the decoded flag.
• the motion vector of adjacent decoded blocks can also be used to determine whether or not to perform motion refinement. For example, if a difference between the initial motion vector predictor for the current block and the at least one motion vector of adjacent decoded blocks is smaller than a third threshold, the initial motion vector predictor is determined to be refined.
• the texture level can also be used. For example, if a texture level of a plurality of pixels of adjacent decoded blocks exceeds a fourth threshold, the initial motion vector predictor is determined to be refined.
• a method for video encoding comprising: accessing an initial motion vector predictor, the initial motion vector predictor associated with a first motion resolution; determining whether or not to explicitly signal a refinement of the initial motion vector predictor, based on a motion vector difference corresponding to the initial motion vector predictor, the refinement being associated with a second motion resolution, and the second motion resolution being higher than the first motion resolution; and encoding the motion vector difference.
• a magnitude of the motion vector difference is smaller than the first threshold but not the second threshold, the refinement of the initial motion vector predictor is not explicitly signaled.
• the motion vector of adjacent reconstructed blocks can also be used to determine whether or not to perform motion refinement. For example, if a difference between the initial motion vector predictor for the current block and the at least one motion vector of adjacent reconstructed blocks is smaller than a third threshold, the initial motion vector predictor is determined to be refined.
• the texture level can also be used. For example, if a texture level of the plurality of pixels exceeds a fourth threshold, the initial motion vector predictor is determined to be refined.
• the present embodiments also provide an apparatus for performing these methods.
• the present embodiments also provide a non-transitory computer readable storage medium having stored thereon instructions for performing any of the methods described above.
• the present embodiments also provide a bitstream generated according to the methods described above. BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates an exemplary HEVC (High Efficiency Video Coding) encoder.
• FIG. 2A is a pictorial example depicting the positions of five spatial candidates ⁇ ai, bi, bo, ao, b 2 ⁇ for a current block
• FIG. 2B is a pictorial example depicting an exemplary motion vector representation using AMVP (Advanced Motion Vector Prediction)
• FIG. 2C is a pictorial example depicting motion-compensated prediction.
• AMVP Advanced Motion Vector Prediction
• FIG. 3 illustrates a block diagram of an exemplary HEVC video decoder.
• FIG. 4 illustrates an exemplary method for performing motion vector refinement at a decoder, according to an embodiment of the present principles.
• FIG. 5 is a pictorial example depicting pixel positions for integer pixels, half pixels, quarter pixels and eighth pixels.
• FIG. 6A illustrates an exemplary PU to be decoded
• FIG. 6B is a pictorial example illustrating an L-shape set of neighboring reconstructed samples and an L-shape set of prediction samples for measuring discontinuity.
• FIG. 7A is a pictorial example illustrating local gradients
• FIG. 7B is a pictorial example illustrating second order moments of gradients.
• FIG. 8 illustrates an exemplary method for performing motion vector refinement at an encoder, according to an embodiment of the present principles.
• FIG. 9 illustrates an exemplary method for performing motion vector predictor refinement at a decoder, according to an embodiment of the present principles.
• FIG. 10 illustrates an exemplary method for performing motion vector predictor refinement at an encoder, according to an embodiment of the present principles.
• FIG. 11 illustrates an exemplary method for performing motion vector predictor refinement with automatic motion refinement activation at a decoder, according to an embodiment of the present principles.
• FIG. 12 illustrates an exemplary method for performing motion vector predictor refinement with automatic motion refinement activation at an encoder, according to an embodiment of the present principles.
• FIG. 13 illustrates an exemplary method for determining whether or not to use adaptive motion refinement for a particular MVP, according to an embodiment of the present principles.
• FIG. 14 illustrates a block diagram of an exemplary system in which various aspects of the exemplary embodiments of the present principles may be implemented.
• FIG. 1 illustrates an exemplary HEVC (High Efficiency Video Coding) encoder 100.
• HEVC High Efficiency Video Coding
• a picture is partitioned into one or more slices where each slice can include one or more slice segments.
• a slice segment is organized into coding units, prediction units and transform units.
• the HEVC specification distinguishes between “blocks” and “units,” where a "block” addresses a specific area in a sample array (e.g., luma, Y), and the “unit” includes the collocated block of all encoded color components (Y, Cb, Cr, or monochrome), syntax elements and prediction data that are associated with the block (e.g., motion vectors).
• a picture is partitioned into coding tree blocks (CTB) of square shape with a configurable size, and a consecutive set of coding tree blocks is grouped into a slice.
• a Coding Tree Unit (CTU) contains the CTBs of the encoded color components.
• a CTB is the root of a quadtree partitioning into Coding Blocks (CB), and a Coding Block is partitioned into one or more Prediction Blocks (PB) and forms the root of a quadtree partitioning into Transform Blocks (TBs).
• a Coding Unit includes the Prediction Units (PUs) and the tree- structured set of Transform Units (TUs)
• PUs Prediction Units
• TUs tree- structured set of Transform Units
• a PU includes the prediction information for all color components
• a TU includes residual coding syntax structure for each color component.
• the size of a CB, PB and TB of the luma component applies to the corresponding CU, PU and TU.
• the term "block” can be used to refer to any of CTU, CU, PU, TU, CB, PB and TB.
• the "block” can also be used to refer to a macroblock, a partition and a sub-block as specified in H.264/AVC or other video coding standards, and more generally to refer to an array of data of various sizes.
• a picture is encoded by the encoder elements as described below.
• the picture to be encoded is processed in units of CUs.
• Each CU is encoded using either an intra or inter mode.
• intra prediction 160
• motion estimation (175) and compensation (170) are performed.
• the encoder decides (105) which one of the intra mode or inter mode to use for encoding the CU, and indicates the intra/inter decision by a prediction mode flag.
• Prediction residuals are calculated by subtracting (110) the predicted block from the original image block.
• CUs in intra mode are predicted from reconstructed neighboring samples within the same slice.
• a set of 35 intra prediction modes is available in HEVC, including a DC, a planar and 33 angular prediction modes.
• the intra prediction reference is reconstructed from the row and column adjacent to the current block. The reference extends over two times the block size in horizontal and vertical direction using available samples from previously reconstructed blocks.
• an angular prediction mode is used for intra prediction, reference pixels can be copied along the direction indicated by the angular prediction mode.
• the applicable luma intra prediction mode for the current block can be coded using two different options. If the applicable mode is included in a constructed list of three most probable modes (MPM), the mode is signaled by an index in the MPM list. Otherwise, the mode is signaled by a fixed-length binarization of the mode index.
• the three most probable modes are derived from the intra prediction modes of the top and left neighboring blocks.
• the corresponding coding block is further partitioned into one or more prediction blocks. Inter prediction is performed on the PB level, and the corresponding PU contains the information about how inter prediction is performed.
• the motion information i.e., motion vector and reference index
• AM VP advanced motion vector prediction
• a video encoder or decoder In the merge mode, a video encoder or decoder assembles a candidate list based on already coded blocks, and the video encoder signals an index for one of the candidates in the candidate list. At the decoder side, the motion vector (MV) and the reference picture index are reconstructed based on the signaled candidate.
• the set of possible candidates in the merge mode consists of spatial neighbor candidates, a temporal candidate, and generated candidates.
• FIG. 2A shows the positions of five spatial candidates ⁇ ai, bi, bo, ao, b 2 ⁇ for a current block 210. For each candidate position, the availability is checked according to the order of ai, bi, bo, ao, b 2 , and then the redundancy in candidates is removed.
• the maximum number of merge candidates N is specified in the slice header. If the number of merge candidates is larger than N, only the first N - 1 spatial candidates and the temporal candidate are used. Otherwise, if the number of merge candidates is less than N, the set of candidates is filled up to the maximum number N.
• AMVP a video encoder or decoder assembles candidate lists based on motion vectors determined from already coded blocks. The video encoder then signals an index in the candidate list to identify a motion vector predictor (MVP) and signals a motion vector difference (MVD). At the decoder side, the motion vector (MV) is reconstructed as MVP+MVD.
• MVP motion vector predictor
• MVP motion vector difference
• the first spatial motion candidate is chosen from left positions ⁇ ao, ai ⁇ and the second one from the above positions ⁇ bo, bi, b 2 ⁇ , while keeping the searching order as indicated in the two sets. If the number of motion vector predictors is not equal to two, the temporal MV prediction candidate can be included. If the temporal candidate is not available, a zero motion vector is used to fill the set of candidates.
• FIG. 2B illustrates an exemplary motion vector representation using AMVP.
• a motion vector (MVcummt) can be obtained through motion estimation.
• MVieft motion vector from a left block (230)
• MVabove motion vector from the above block (220)
• MVPcurrent motion vector predictor
• the precision of the motion information for motion compensation is one quarter- sample (also referred to as quarter-pel or 1/4-pel) for the luma component and one eighth-sample (also referred to as 1/8-pel) for the chroma components.
• a 7-tap or 8-tap interpolation filter is used for interpolation of fractional- sample pixel positions, i.e., 1/4, 1/2 and 3/4 of full pixel locations in both horizontal and vertical directions can be addressed for luma.
• the prediction residuals are then transformed (125) and quantized (130).
• the quantized transform coefficients, as well as motion vectors and other syntax elements, are entropy coded (145) to output a bitstream.
• the encoder may also skip the transform and apply quantization directly to the non-transformed residual signal on a 4x4 TU basis.
• the encoder may also bypass both transform and quantization, i.e., the residual is coded directly without the application of the transform or quantization process.
• direct PCM coding no prediction is applied and the coding unit samples are directly coded into the bitstream.
• the encoder decodes an encoded block to provide a reference for further predictions.
• the quantized transform coefficients are de-quantized (140) and inverse transformed (150) to decode prediction residuals.
• a filter (165) is applied to the reconstructed picture, for example, to perform deblocking/SAO (Sample Adaptive Offset) filtering to reduce blockiness artifacts.
• the filtered image is stored at a reference picture buffer (180).
• FIG. 3 illustrates a block diagram of an exemplary HEVC video decoder 300.
• a bitstream is decoded by the decoder elements as described below.
• Video decoder 300 generally performs a decoding pass reciprocal to the encoding pass as described in FIG. 1, which performs video decoding as part of encoding video data.
• the input of the decoder includes a video bitstream, which may be generated by video encoder 100.
• the bitstream is first entropy decoded (330) to obtain transform coefficients, motion vectors, and other coded information.
• the transform coefficients are de-quantized (340) and inverse transformed (350) to decode the prediction residuals.
• the predicted block may be obtained (370) from intra prediction (360) or motion-compensated prediction (i.e., inter prediction) (375).
• AMVP and merge mode techniques may be used to derive motion vectors for motion compensation, which may use interpolation filters to calculate interpolated values for sub-integer pixels of a reference block.
• a filter (365) is applied to the reconstructed image.
• the filtered image is stored at a reference picture buffer (380).
• the inter prediction mode allows for predicting one block (for example, Prediction Unit) using at least one motion compensated block from previously reconstructed/decoded pictures.
• a current block 255
• blocks 225 and 245 are co-located blocks in reference pictures
• blocks 215 and 235 are blocks used for motion-compensated prediction.
• At least one reference index e.g., refldxO
• DPB Decoded Pictures Buffer
• MVD Motion Vector Difference
• addition reference index e.g., refldxl
• motion information are encoded in order to reconstruct the motion vectors (e.g., mvO and mvl).
• the motion vectors can be inferred from previously decoded data (e.g., merge mode in HEVC).
• the reconstruction of MV values can be performed as follows:
• MV X MVPx + MVDx
• MV Y MVP Y + MVD Y
• MVP (MVP X , MVP Y ) is the motion vector predictor built from previously reconstructed data
• MVD (MVD X , MVD Y ) is the motion vector difference that is encoded and transmitted in the bitstream.
• the MVD values are usually encoded at a precision corresponding to the decoded MV values.
• HEVC uses one-quarter pixel (i.e., 1/4-pel) as the motion vector resolution.
• MV resolution for example, from 1/4-pel to 1/8-pel
• the coding of the MVD data can have a relatively high bitrate cost with respect to other data encoded per block.
• the overall compression efficiency may not necessarily improve with the MV resolution.
• Lakshman defines a set of rules known to both the encoder and decoder to infer the MV resolution, between quarter- sample MV resolution and 1/6-sample MV resolution, without any explicit block-by-block forward signaling.
• a high resolution MV is transmitted as a regular quarter- sample MV augmented with refinement information, which increases the resolution of the motion vectors from a quarter- sample resolution to one-sixth of a sample.
• the reconstructed MV components that point to integer or half-sample positions are left unaltered.
• the decoder infers the presence of refinement using the following conditions:
• the MV refinement information is always sent.
• the MV refinement is sent for the predictions that access samples from a reference picture that contains high texture.
• the MV refinement is sent only for pictures from a pre-defined reference picture list.
• MVD between the motion vector and predicted motion vector of a PU can be coded with either quarter-pel resolution or integer-pel resolution.
• the MVD resolution is controlled at coding unit (CU) level and an integer MVD resolution flag is conditionally signaled for each CU that has at least one non-zero MVD components.
• the default quarter-pel MV resolution is used for all PUs belonging to the CU. Otherwise, all PUs coded with AMVP mode belonging to the CU use integer MV resolution, while the PUs coded with merge mode still use quarter-pel MV resolution.
• the AMVP candidate list is filled with integer MV by rounding quarter-pel MVs to integer-pel MVs.
• a first resolution MVD (for example, 1/4-pel) is received in the bitstream, and the decoder obtains an initial motion vector based on the MVD, and refines the initial motion vector to obtain a second motion resolution (for example, 1/8-pel) higher than the first resolution, using already decoded neighboring samples.
• the refinement of motion information is also performed at the encoder to avoid mismatch. Because the motion refinement is performed at both the encoder and decoder, no additional information is transmitted in the bitstream to indicate the motion refinement, for example, no explicit signaling is used to indicate the refinement of a motion vector from 1/4-pel to 1/8-pel.
• merge mode is used for the current block (i.e., no MVD is received in the bitstream), and the initial motion vector is obtained as a motion vector predictor in the candidate list (possibly rounded to the first resolution) is refined to obtain the second motion resolution.
• the motion information refinement may be performed using motion estimation at the encoder or decoder. Comparing with an approach that uses the first motion resolution (for example, 1/4-pel) without motion resolution refinement, the proposed embodiment may improve the motion accuracy without the overhead of transmitting the refinement motion information. Comparing with an approach that uses the second motion resolution (for example, 1/8-pel) without motion resolution refinement at the decoder, the proposed embodiment may reduce the overhead of transmitting the motion refinement information.
• the decoder according to the present principles may also perform motion search, and thus may be more complex than a decoder that does not need motion search.
• FIG. 4 illustrates an exemplary method 400 for performing motion vector refinement at a decoder, according to an embodiment of the present principles.
• a decoder can refine a motion vector resolution from 1/4-pel to 1/8-pel.
• the present principles can be applied to refinement between other motion resolutions, for example, but not limited to, from integer-pel to 1/4-pel, froml/4-pel to 1/6-pel.
• MVP MV predictor
• MVP MVP + MVD
• the MV predictors may also be generated at 1/8 pel. Whether the MV predictor is generated at 1/4-pel or 1/8-pel should be consistent with what the encoder has used.
• the samples of a motion-compensated prediction block are obtained from those of a corresponding block at a position displaced by the motion vector in a reference picture identified by a reference picture index.
• the motion vector is not an integer
• fractional sample interpolation is used to generate the prediction samples.
• Ival[x] ⁇ ⁇ ] xs[x + iMV - N/2 (2)
• x is the pixel location
• the filter coefficients for 1/4-pel interpolation in HEVC are as follows:
• the motion refinement process may be regarded as motion estimation, with a range related to the motion resolution before refinement.
• the motion search range include candidates around the initial motion vector.
• the search candidates for motion refinement can be MVX 0 - AMVX ⁇ MVX 0 + AMVX , MVY 0 - AMVY ⁇ MVY 0 + AMVY, in the horizontal direction and vertical direction, respectively, wherein MVX 0 and MVY 0 are horizontal and vertical components of the initial motion vector MV 0 , respectively, and AMVX and AMVY define the search range in the horizontal and vertical directions, respectively.
• the refinement candidates in the horizontal direction can be (MVX 0 — kxstep2, MVX 0 + kxstep2, where k is an integer and is defined as
• FIG. 5 illustrates pixel positions for integer pixels, half pixels, quarter pixels and eighth pixels. For ease of notation, we may also refer to those candidates as motion refinement candidates, and we denote a predicted block built by motion
• An exemplary set of search candidates includes the positions within box 520 when (MVX 0 MVY 0 ) corresponds to position 510.
• the search range, and more generally, the set of search candidates can be different from what is shown in FIG. 5. The same set of search candidates should be used at the encoder and decoder.
• the decoder obtains MVP and MVD at a motion resolution that is used for the decoded motion vector, and no motion refinement is performed at the decoder.
• FIG. 6A illustrates an exemplary PU (650) to be decoded.
• PUs 610, 620, 630, 640
• an L-shape set of decoded samples (670) in neighboring blocks may be used for refining the motion vector for the current PU (650).
• PUs can be in different sizes or shapes from what are shown in FIG. 6A, and a larger or smaller set of neighboring reconstructed samples can be used for refining motion vector for the current PU.
• the discontinuity based on the L-shape set of decoded samples (670) in neighboring blocks (referred to as "neighboring L-shape") and an L-shape set of samples (680) in a current prediction block.
• the discontinuity can be measured as the Sum of Absolute Difference (SAD) between the reconstructed samples (n) and the closest motion-refinement prediction sample (p), as illustrated in FIG. 6B.
• SAD Sum of Absolute Difference
• p closest motion-refinement prediction sample
• the refined motion vector difference can be calculated as:
• MVD efine argmin ⁇ p
• MVD refine argmin ⁇ p
• Res(p) is the residual at sample p.
• MV 0 can be set to MVD+MVP in AMVP or the one signaled in the candidate list in merge mode, wherein MVD and MVP are obtained as specified by HEVC.
• MV 0 is the motion vector the decoder obtained without performing motion search at the decoder.
• Motion refinement can be viewed as motion search at the decoder, with a set of candidate motion vectors, at a higher motion resolution, selected from around the initial motion vector.
• the choice of a best motion vector may be the one that minimizes a certain criterion, for example, the discontinuity measure as described in Eq. (4) or (5). That is, after an initial motion vector MV 0 is obtained, a motion search is further performed to refine the initial motion vector.
• the extra complexity in a decoder is usually small because only a small set of search candidates around the initial motion vector needs to be checked.
• MV MV 0 + MVD refine (6)
• the block corresponding to the refined MV in the reference picture is used as the prediction block for decoding the PU, for example, using the interpolation filters as described above.
• motion refinement enables an encoder to encode an MVD at a low resolution, and thus reduces the cost of encoding motion information compared with encoding MVD at a full resolution, while the decoder can still recover the MV at a full resolution.
• SAD Sum of Squared Error
• I(x+d) I(x) + g(x).d (7)
• I(x) is the picture sample value at location x
• g is a 2x2 matrix estimated with local gradients.
• the residuals can be included when calculating P(p).
• the local gradients at position p (x p , y p ) can be expressed as shown in FIG. 7 A:
• VD refine argmin ⁇ p ⁇
• the gradients can be derived similarly.
• it can be processed as it is at the left or upper boundary or can be processed twice (once as the boundary, and once as the upper).
• VD efine argmin ⁇ p ⁇
• the discontinuity can also be calculated as the sum of the absolute value of the local gradients and second order moments:
• MVD efine argmin ⁇ p ⁇
• FIG. 8 illustrates an exemplary method 800 for performing motion vector refinement at an encoder, according to an embodiment of the present principles.
• the output of method 800 may be used as an input bitstream to method 400.
• Motion estimation (810) is performed at the 1/8-resolution to obtain a motion vector (MV).
• the encoder checks whether it is more efficient to encode the motion vector using adaptive motion refinement or not. From steps 820-840, the encoder checks the MV encoding cost with motion refinement, for example, using the RD (Rate-Distortion) cost.
• the encoder checks the MV encoding cost without motion refinement.
• a motion vector predictor list is built at the 1/4-pel resolution, for example, using the motion vector predictor candidate list from AMVP, a rounded version of a 1/8-pel initial motion vector predictor or an average of neighboring motion vectors, consistent with how a corresponding decoder builds the motion vector predictor list.
• MVD motion vector difference
• the motion vector predictor candidate list may be built at 1/8-pel resolution at step 815, and the motion vector difference MVD is rounded to 1/4-pel at step 820. Note that MVo may be different from MV because of the rounding applied to the MVP or MVD.
• the residuals can then be calculated (827) based on MV*.
• the encoding cost of the adjusted motion vector (MV * ) can be estimated using RD (Rate-Distortion) cost at step 830.
• the encoder checks whether the current adjusted motion vector has a smaller RD cost than the current Best_RDcost. If yes, parameters Best_RDcost, Best_MV, Best_MVD are set to the current RD cost, current adjusted motion vector, and current MVD, and some other relevant encoding information may also be stored.
• a motion vector predictor list is built at the 1/8-pel resolution, for example, using the motion vector predictor candidate list from AMVP.
• Step 845 is similar to step 815, except that the encoder does not adjust the motion resolution to 1/4-pel.
• the MVD is calculated (850) based on the MVP at the 1/8-pel resolution.
• the encoder checks whether the current motion vector has a smaller RD cost than the current Best_RDcost. If yes, parameters Best_RDcost, Best_MV and Best_MVD are set to the current RD cost, current motion vector, and current MVD, and the adaptive motion refinement flag is set to false (0). Other relevant encoding information may also be stored.
• the motion refinement can be applied to all motion vectors corresponding to the motion vector predictors, or can be applied to a subset. For example, motion refinement is used for AMVP motion vector predictors only, or to the merge mode only.
• the encoder decides whether to use adaptive motion refinement based on the encoding cost and signals the choice through a flag in the bitstream.
• the encoder may decide whether to use adaptive motion refinement based on the video characteristics without checking the encoding cost, for example, as described further below or in Lakshman and Chen. Consequently, the encoder may only need to perform part of method 800 (for example, the part with motion refinement, or the part without motion refinement).
• an additional syntax element Best_flag may need to be sent according to method 800. However, sending Best_flag may still be more efficient than sending the MVD at the 1/8-pel resolution since the high-resolution portion of the motion vector usually is random and expensive to encode.
• the encoder can reach a 1/8-pel motion resolution while the motion vector difference MVD is transmitted in the bitstream at a 1/4-pel motion resolution. Accordingly, the MVD may require fewer bits to be encoded. For example, as shown in TABLE 1, a motion vector (MV) for a current block from the motion estimation (810) is 3.625, a motion vector predictor list (815) includes ⁇ 3.0, ... ⁇ .
• MVD 3.0
• MVD 850
• MVD is rounded to 0.5 (1/4-pel)
• the refined motion is the same as the MV obtained from motion estimation and the MVD is transmitted at 1/4-pel, and thus may need fewer bits than when no motion refinement is used (i.e., the MVD is transmitted at 1/8-pel). Consequently, the encoder is likely to choose to enable motion refinement.
• the refined motion vector is the same as the motion vector from motion estimation. It should be noted the refined motion vector may be different from the motion vector obtained from motion estimation.
• refinement to an initial motion vector that is generated based on a motion vector predictor MVP and a motion vector difference MVD.
• the refinement can be performed with respect to the motion vector predictor (without including MVD).
• an initial motion vector predictor MVP 0
• the motion vector predictor can be refined using the reconstructed L-shape (670).
• the decoder may form an MC L-shape (680) corresponding to a motion vector predictor around the initial motion vector predictor, for example, MVP 0 +
• the decoder can compare a difference, for example,
• both the reconstructed L-shape (670) and MC L-shape (680) are based on decoded samples, such that the same process can be performed at both the encoder and decoder sides.
• the motion refinement for the motion vector predictor can be viewed as a motion search with a search range including a few sub-sample displacements at a full motion resolution around the initial motion vector predictor.
• a motion vector predictor MVPo at 510 may be refined using the search candidates within 520 as illustrated in FIG. 5.
• different sets of search candidates may be used from what is shown in FIG. 5.
• the motion refinement can be performed on a rounded version of the initial motion vector predictor ( round(MVP 0 ) ), and the search range for the motion refinement includes sub- sample displacements at a full motion resolution around the rounded motion vector predictor.
• the search range for the motion refinement includes sub- sample displacements at a full motion resolution around the rounded motion vector predictor.
• the rounded version of MVP 0 may be at an interger-pel, half-pel or quarter-pel resolution. This is because the actual motion vector is more likely to be concentrated around a motion vector at the lower resolution, and the rounded version of the initial motion vector predictor may provide a better starting point for search.
• the motion refinement may be performed with respect to an average value of neighboring motion vectors that are used in the MVP candidate list.
• the motion refinement may use an average of the left and above motion vectors (MV left + MV above )/2 as the initial motion vector predictor, and then perform a motion search around the initial motion vector predictor.
• motion refinement is usually selected in an almost, or relatively, uniform motion area.
• the predictor candidate list may be reduced to use only one (left or above) candidate in the list, and thus, reducing the number of possible candidates. This may improve the compression efficiency as no index of the AMVP list needs to be encoded or transmitted in the bitstream.
• FIG. 9 illustrates an exemplary method 900 for performing motion vector predictor refinement at a decoder, according to an embodiment of the present principles.
• a decoder can refine a motion vector predictor resolution from 1/4-pel to 1/8-pel.
• the decoder checks (910) whether adaptive motion vector resolution is enabled, for example, using a flag in the bitstream, or using the existing methods as described above. If adaptive motion vector resolution is enabled, the decoder generates MV predictor (MVP) at 1/4-pel resolution (920).
• MVP MV predictor
• the initial motion vector predictor can be generated, for example, but not limited to, using the AMVP mode of HEVC, using an average of neighboring motion vectors, or using a rounded version of a motion vector predictor.
• the motion vector predictor can then be refined to 1/8-pel resolution (930), for example, using the embodiments described above.
• the decoder decodes MVD at 1/8-pel resolution (940).
• the decoder obtains MVP and MVD at a motion resolution that is used for the decoded motion vector, and no motion refinement is performed at the decoder.
• FIG. 10 illustrates an exemplary method 1000 for performing motion vector predictor refinement at an encoder, according to an embodiment of the present principles.
• the output of method 1000 may be used as an input bitstream to method 900.
• Motion estimation (1010) is performed in the 1/8 resolution to obtain a motion vector MV.
• the encoder checks whether it is more efficient to encode the motion vector using adaptive motion refinement or not. From steps 1020-1040, the encoder checks the MV encoding cost with motion refinement, for example, using the RD (Rate-Distortion) cost. From steps 1045-1075, the encoder checks the MV encoding cost without motion refinement. Then motion compensation is performed based on the final MV (Best_MV) and the residuals can be calculated (1085). The residuals, the final MVD (Best_MVD) and the adaptive motion refinement flag (Best_flag) are encoded (1090) into the bitstream.
• RD Random-Distortion
• a motion vector predictor list is built at the 1/4-pel resolution, for example, using the motion vector predictor candidate list from AMVP, an rounded version (for example, to the closet integer at the desired resolution) of an initial motion vector predictor or an average of neighboring motion vectors, consistent with how a corresponding decoder builds the motion vector predictor list.
• the MVP list may contain only one MVP in some cases.
• the motion vector predictor list can also be built at the 1/8-pel resolution.
• one advantage of using a lower resolution (1/4-pel) is that it may avoid drift in flat areas, where the RD optimization cannot differentiate between MV at the 1/8-pel or 1/4-pel resolution.
• Using a reduced resolution allows a sort of smoothing of the MV predictor which may reduce the MV noise. Also, if the size of the search window for the refinement is relatively small (+1/4 for 1/8 refinement), the precision of the starting/center MV for the search window may change the result.
• MVP refinement is performed (1020), for example, as described above for the decoder.
• the encoding cost of the adjusted motion vector (MV * ) can be estimated using RD cost at step 1030.
• the encoder checks whether the current adjusted motion vector has a smaller RD cost than the current Best_RDcost. If yes, parameters Best_RDcost, Best_MV and Best_MVD are set (1040) to the current RD cost, current adjusted motion vector, and current MVD, and Best_flag remains true (1).
• a motion vector predictor list is built at the 1/8-pel resolution, for example, using the motion vector predictor candidate list from AMVP.
• the MVD is calculated (1050) based on the MVP at the 1/8-pel resolution.
• the encoding cost of the motion vector (MV) can be estimated using RD cost at step 1055.
• the encoder checks whether the current motion vector has a smaller RD cost than the current Best_RDcost. If yes, parameters Best_RDcost, Best_MV and Best_MVD are set (1075) to the current RD cost, current motion vector, and current MVD, and the adaptive motion refinement flag (Best_flag) is set to false (0).
• the encoder decides whether to use adaptive motion refinement based on the encoding cost and signals the choice through a flag in the bitstream.
• the encoder may decide whether to use adaptive motion refinement based on the video characteristics without checking the encoding cost, for example, as described further below or in Lakshman and Chen. Consequently, the encoder may only need to perform part of method 1000 (for example, the part with motion refinement, or the part without motion refinement).
• the MV predictor can be more accurate. Accordingly, the MVD may statistically have lower values, and the coding cost can then be reduced.
• a motion vector (MV) for a current block from the motion estimation (1010) is 3.625
• a motion vector predictor list (1015) includes ⁇ 3.0, ... ⁇ .
• the MVD to be encoded is smaller and may need fewer bits to be encoded.
• using motion refinement may improve the compression efficiency, and thus, the encoder is likely to choose to enable adaptive motion refinement.
• MVD When MVD is 0, for example, when the merge mode is used, steps 1025 and 1050 are not needed, and at step 1040 and 1075, Best_MVD does not need to be calculated, and at step 1090, Best_MVD does not need to be encoded. Note that when MVD is 0, method 1000 may become the same as method 800.
• the motion refinement can be applied to all motion vectors corresponding to the motion vector predictors, or can be applied to a subset. For example, motion refinement is used for AMVP motion vector predictors only, or to the merge mode only.
• a flag for example, Best_flag as shown in FIG. 8 or FIG. 10.
• the encoder can indicate whether adaptive motion vector resolution is enabled without an explicit flag, and the decoder can also decide whether adaptive motion vector resolution without referring to an explicit flag.
• motion similarity The motion of the current block is similar to the motion of surrounding blocks, such that an encoder or decoder can use motion vectors of surrounding blocks for motion refinement.
• Textureness (or texture level): The current block and surrounding blocks contain some texture which may allow a robust sub-pixel motion refinement.
• Motion vector difference (MVD) is available at both the encoder and decoder, and can be used to determine whether to use automatic adaptive motion refinement or to explicitly signal the adaptive motion refinement.
• the motion similarity criterion may be measured using one or more of the following conditions:
• MVPieft and MVPabove exist, namely, a motion field exists around the current block. More generally, there are one or more neighboring blocks that have motion vectors.
• MVPcurrentl ⁇ T2 This condition can also be a different logical combination of these three sub-conditions: IMVPkft - MVPcurrentl ⁇ T2, IMVPabove - MVPcurrentl ⁇ T2, and IMVPleftabove - MVPcurrentl ⁇ T2. That is, the motion vectors of the surrounding blocks are similar and motion field around the current block is somewhat uniform.
• T2 we use the same T2 to check the difference between MVPieft and MVP CU rrent, between MVPabove and MVP CU rrent, and between MVPieftabove and MVP CU rrent. It should be noted that different thresholds can be used for these differences.
• the textureness criterion may be measured using one or more of the following conditions:
• Texture(L) > T3 where L is the neighboring area used for performing motion refinement, for example, 670 as shown in FIG. 6A, and texture(X) is a measure of texturing, for example, the variance in luminance of X. That is, the neighboring area has some texture.
• MVP is the selected motion vector predictor that corresponds to MVD signaled in the bitstream, such that both the encoder and decoder can use the same MVP for checking this condition
• Err(X,Y) is a measure of error between a group of pixels X and a group of pixels Y, for example, SAD, HAD or SSE
• mc(X, v, I) is the motion compensation of the group of pixels X using the motion vector v in the reference image I
• Iref is the reference image associated with the motion vector predictor MVP
• T4 is a threshold on error similarity
• MVP+MVr is the motion vector predictor after refinement.
• the MVP may be at a lower motion resolution as described before, for example, being integer rounded.
• the automatic motion refinement activation may be based on all conditions under both motion similarity or textureness criteria, or may also use a subset of the conditions. Whether to signal the motion refinement activation or deactivation can be based on the motion vector difference (MVD).
• MVD motion vector difference
• both the encoder and decoder have access to MVD, and can use MVD to determine the motion refinement activation in the same manner in order to synchronize the encoder and decoder.
• the encoder and decoder may automatically deactivate motion refinement, without explicit signalling.
• a temporal candidate when a temporal candidate is used to build the motion vector predictor list, that is, when MVPieft and MVPabove do not co-exist or are the same, conditions 1) and 2) in the motion similarity criterion are not used.
• the encoder may choose whether or not to use the temporal candidate for automatic refinement.
• FIG. 11 illustrates an exemplary method 1100 for performing motion vector predictor refinement with automatic motion refinement activation or deactivation at a decoder, according to an embodiment of the present principles.
• the decoder For a block to be decoded, the decoder generates (1110) MV predictor (MVP CU rrent) and decodes (1120) the MV difference (MVD).
• MVP CU rrent MV predictor
• MVD the MV difference
• the motion refinement is automatically activated without a flag.
• the decoder decodes (1140) a flag (for example, Refine_flag) indicating whether motion refinement may be used. If the flag is true (1145), the decoder continues to step 1155. Otherwise, if the flag is false (1145), the motion vector is obtained (1180) based on the MVP and MVD. [121] In FIG. 11, the decoder automatically deactivates or activates motion refinement in some conditions, and relies on a flag to deactivate or activate motion refinement in other conditions. The same conditions are used by a corresponding encoder to ensure the synchronization between the encoder and decoder.
• a flag for example, Refine_flag
• method 1100 can also skip steps 1130-1145. That is, when IMVDI > Tl, the decoder performs step 1180 without motion refinement.
• Other variations can also be implemented, for example, but not limited to, skipping step 1155 and/or step 1165, checking one of the two conditions at step 1155.
• FIG. 12 illustrates an exemplary method 1200 for performing automatic motion refinement at an encoder, according to an embodiment of the present principles.
• the output of method 1200 may be used as an input bitstream to method 1100.
• the encoder may access a video sequence to be encoded as input. Additionally, the encoder may set the parameters to initial values, for example, set Best_RDcost to a large value.
• Motion estimation (1210) is performed at the 1/8-pel resolution to obtain a motion vector MV.
• a motion vector predictor list is built, for example, using the motion vector predictor candidate list from AMVP.
• a rounded version (for example, to the closet integer at the desired resolution) of an initial motion vector predictor or an average of neighboring motion vectors may be used, consistent with how a corresponding decoder builds the motion vector predictor list.
• the MVP list may contain only one MVP in some cases.
• the motion vector predictor list can also be built at other resolutions.
• the encoder checks whether it is more efficient to encode the motion vector using adaptive motion refinement or not and sets a Refine_flag to 0 or 1. When motion refinement is more efficient, Refine_flag is set to 1, and otherwise to 0. A corresponding MVD is also computed at step 1225.
• FIG. 13 illustrates an exemplary method 1300 for determining whether or not to use adaptive motion refinement for a particular MVP, according to an embodiment of the present principles.
• Method 1300 can be used to implement step 1225 of method 1200.
• MVP* refined motion vector predictor
• RDCostl RD Cost
• a RD Cost (RDCost2) is estimated (1370) when motion refinement is not used.
• the RD costs with and without motion refinement are compared (1375). If RDCostl is smaller, then Refine_flag is set (1380) to 1, and MVD is set to MV - MVP*. Otherwise, Refine_flag is set (1390) to 0, and MVD is set to MV - MVP.
• MVP motion vector predictor
• the encoder checks whether IMVDI ⁇ Tl. If yes, the encoder further checks (1235) whether Refine_flag is equal to 1. If Refine_flag is set to 1, the encoder estimates (1270) the RD cost.
• RD cost is smaller than the current Best_RDCost (1275)
• parameters Best_RDcost and Best_MVD are set (1280) to the current RD cost and current MVD, and Write_flag is set to no, indicating that no explicit signaling is used to indicate adaptive motion refinement. That is, if the current MVP is selected for encoding, the motion refinement would be automatically activated without the need to send a flag.
• the encoder estimates (1240) the RD cost. If the RD cost is smaller than the Best_RDCost (1245), parameters Best_RDcost and Best_MVD are set (1250) to the current RD cost and current MVD. The encoder then checks (1255) whether IMVDI ⁇ Tl + S * V2/2. If yes, Write_flag is set to yes. Here, if a motion vector predictor corresponding to conditional branch 1260 is selected, whether motion refinement is activated would be explicitly signaled based on Refine_flag.
• Write_flag is set (1265) to no. That is, if a motion vector predictor corresponding to conditional branch 1265 is selected, the motion refinement would be automatically deactivated without the need to send a flag.
• the encoder checks (1285) whether the end of the MVP list is reached. If yes, the encoder encodes the Best_MVD, the index of the selected MVP, and corresponding residual if any. If Write_flag is set to yes, the Refine_flag is also encoded. Otherwise, if the condition at 1285 is not satisfied, the control is returned to step 1225. If the merge mode is selected, Best_MVD does not need to be encoded at step 1290. Corresponding to method 1100, method 1200 can also be varied from what is shown in FIG. 12, for example, steps 1240-1260 can be skipped.
• FIG. 14 illustrates a block diagram of an exemplary system in which various aspects of the exemplary embodiments of the present principles may be implemented.
• System 1400 may be embodied as a device including the various components described below and is configured to perform the processes described above. Examples of such devices, include, but are not limited to, personal computers, laptop computers, smartphones, tablet computers, digital multimedia set top boxes, digital television receivers, personal video recording systems, connected home appliances, and servers.
• System 1400 may be communicatively coupled to other similar systems, and to a display via a communication channel as shown in FIG. 14 and as known by those skilled in the art to implement the exemplary video system described above.
• the system 1400 may include at least one processor 1410 configured to execute instructions loaded therein for implementing the various processes as discussed above.
• Processor 1410 may include embedded memory, input output interface and various other circuitries as known in the art.
• the system 1400 may also include at least one memory 1420 (e.g., a volatile memory device, a non-volatile memory device).
• System 1400 may additionally include a storage device 1440, which may include non- volatile memory, including, but not limited to, EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic disk drive, and/or optical disk drive.
• the storage device 1440 may comprise an internal storage device, an attached storage device and/or a network accessible storage device, as non-limiting examples.
• System 1400 may also include an encoder/decoder module 1430 configured to process data to provide an encoded video or decoded video.
• Encoder/decoder module 1430 represents the module(s) that may be included in a device to perform the encoding and/or decoding functions. As is known, a device may include one or both of the encoding and decoding modules. Additionally, encoder/decoder module 1430 may be implemented as a separate element of system 1400 or may be incorporated within processors 1410 as a combination of hardware and software as known to those skilled in the art.
• processors 1410 Program code to be loaded onto processors 1410 to perform the various processes described hereinabove may be stored in storage device 1340 and subsequently loaded onto memory 1420 for execution by processors 1410.
• one or more of the processor(s) 1410, memory 1420, storage device 1440 and encoder/decoder module 1430 may store one or more of the various items during the performance of the processes discussed herein above, including, but not limited to the input video, the bitstream, equations, formula, matrices, variables, operations, and operational logic.
• the system 1400 may also include communication interface 1450 that enables communication with other devices via communication channel 1460.
• the communication interface 1450 may include, but is not limited to a transceiver configured to transmit and receive data from communication channel 1460.
• the communication interface may include, but is not limited to, a modem or network card and the communication channel may be implemented within a wired and/or wireless medium.
• the various components of system 1400 may be connected or communicatively coupled together using various suitable connections, including, but not limited to internal buses, wires, and printed circuit boards.
• the exemplary embodiments according to the present principles may be carried out by computer software implemented by the processor 1410 or by hardware, or by a combination of hardware and software.
• the exemplary embodiments according to the present principles may be implemented by one or more integrated circuits.
• the memory 1420 may be of any type appropriate to the technical environment and may be implemented using any appropriate data storage technology, such as optical memory devices, magnetic memory devices, semiconductor-based memory devices, fixed memory and removable memory, as non-limiting examples.
• the processor 1410 may be of any type appropriate to the technical environment, and may encompass one or more of microprocessors, general purpose computers, special purpose computers and processors based on a multi-core architecture, as non-limiting examples.
• the implementations described herein may be implemented in, for example, a method or a process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method), the implementation of features discussed may also be implemented in other forms (for example, an apparatus or program).
• An apparatus may be implemented in, for example, appropriate hardware, software, and firmware.
• the methods may be implemented in, for example, an apparatus such as, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, such as, for example, computers, cell phones, portable/personal digital assistants ("PDAs”), and other devices that facilitate communication of information between end-users.
• PDAs portable/personal digital assistants
• the appearances of the phrase “in one embodiment” or “in an embodiment” or “in one implementation” or “in an implementation”, as well any other variations, appearing in various places throughout the specification are not necessarily all referring to the same embodiment.
• Determining the information may include one or more of, for example, estimating the information, calculating the information, predicting the information, or retrieving the information from memory.
• Accessing the information may include one or more of, for example, receiving the information, retrieving the information (for example, from memory), storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting the information, or estimating the information.
• Receiving is, as with “accessing”, intended to be a broad term.
• Receiving the information may include one or more of, for example, accessing the information, or retrieving the information (for example, from memory).
• “receiving” is typically involved, in one way or another, during operations such as, for example, storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting the information, or estimating the information.
• implementations may produce a variety of signals formatted to carry information that may be, for example, stored or transmitted.
• the information may include, for example, instructions for performing a method, or data produced by one of the described implementations.
• a signal may be formatted to carry the bitstream of a described embodiment.
• Such a signal may be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal.
• the formatting may include, for example, encoding a data stream and modulating a carrier with the encoded data stream.
• the information that the signal carries may be, for example, analog or digital information.
• the signal may be transmitted over a variety of different wired or wireless links, as is known.
• the signal may be stored on a processor-readable medium.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Compression Or Coding Systems Of Tv Signals (AREA)
• Compression, Expansion, Code Conversion, And Decoders (AREA)

Priority Applications (9)

Applications Claiming Priority (2)

Publications (1)

Family

ID=56411561

Family Applications (1)

Country Status (10)

Cited By (11)

Families Citing this family (43)

Citations (1)

Family Cites Families (9)

• 2016
  • 2016-06-30 EP EP16305827.4A patent/EP3264769A1/en not_active Withdrawn
• 2017
  • 2017-06-27 CN CN201780041091.5A patent/CN109417630A/zh active Pending
  • 2017-06-27 MX MX2018016070A patent/MX2018016070A/es unknown
  • 2017-06-27 BR BR112018077187-2A patent/BR112018077187A2/pt not_active IP Right Cessation
  • 2017-06-27 RU RU2019102368A patent/RU2019102368A/ru not_active Application Discontinuation
  • 2017-06-27 KR KR1020187037849A patent/KR20190031208A/ko not_active Withdrawn
  • 2017-06-27 EP EP17732147.8A patent/EP3479576A1/en not_active Withdrawn
  • 2017-06-27 CA CA3027632A patent/CA3027632A1/en not_active Abandoned
  • 2017-06-27 JP JP2018567658A patent/JP2019519998A/ja not_active Withdrawn
  • 2017-06-27 US US16/312,230 patent/US20190208223A1/en not_active Abandoned
  • 2017-06-27 WO PCT/EP2017/065809 patent/WO2018002024A1/en not_active Ceased

Patent Citations (1)

Non-Patent Citations (5)

Also Published As

Similar Documents

Legal Events