Custom Query (1440 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (13 - 15 of 1440)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ticket Resolution Summary Owner Reporter
#1480 fixed Data Overflow at Adaptive Color Transform HM Implementation swong10
Description

There is not enough precision in the internal stages of the Adaptive Color Transform. Solution : The intermediate ACT stages must use more than 16b to avoid overflow, when not using HIGH_BIT_DEPTH_SUPPORT.

Section 8.6.8.2 (H.265 12/2016 spec) – Residual samples rY[ x ][ y ], rCb[ x ][ y ] and rCr[ x ][ y ] are modified as follows: tmp = rY[ x ][ y ] − ( rCb[ x ][ y ] >> 1 ) (8-338) rY[ x ][ y ] = tmp + rCb[ x ][ y ] (8-339) rCb[ x ][ y ] = tmp − ( rCr[ x ][ y ] >> 1 ) (8-340) rCr[ x ][ y ] += rCb[ x ][ y ] (8-341)

When without HIGH_BIT_DEPTH_SUPPORT, HM C-model using only Short (16b; typedef Short Pel) to store pDst0/1/2.

HM-16.15+SCM-8.5 File : TComYuv.cpp, function Void TComYuv::convert() Pel* pDst0

Int t = yo - (cg>>1); pDst0[x] = cg + t; pDst1[x] = t - (co>>1); pDst2[x] = co + pDst1[x];

Thanks Sam.

#1479 fixed SCM/Spec mismatch in the processing order of merge candidate rounding and merge candidate bi-pred restriction rickxu
Description

In SCM8.5, after getInterMergeCandidates(), the merge candidate bi-pred restriction, i.e. xRestrictBipredMergeCand(), is done before the merge candidate rounding, i.e. roundMergeCandidates(). But in the Spec, the merge candidate list generation follows the below steps, where the bi-pred restriction should be done after the merge candidate rounding. This caused the inconsistence between SCM and Spec.

Step 1: Derive the merge candidates (step 1-8 in spec 8.5.3.2.2, and SCM function is getInterMergeCandidates()) Step 2: Round the merge candidates if needed (step 9 in spec 8.5.3.2.2, and SCM function is roundMergeCandidates()) Step 3: Disallow 8x4 and 4x8 bi-pred merge candidates(step 10 in spec 8.5.3.2.2, and the SCM function is xRestrictBipredMergeCand()) Step 4: Disallow bi-pred merge candidates for some 8x8 CUs (the below part in spec 8.5.3.2.1, and the SCM function is xRestrictBipredMergeCand())

When all of the following conditions are true, refIdxL1 is set equal to −1 and predFlagL1 is set equal to 0. – predFlagL0 is equal to 1. – predFlagL1 is equal to 1. – nPbSw is equal to 8. – nPbSh is equal to 8. – TwoVersionsOfCurrDecPicFlag is equal to 1. – noIntegerMvFlag is equal to 1. – identicalMvs is equal to 0.

#1477 fixed merge candidates rounding in SCM inconsistent with spec libin
Description

The bug was originally reported by Marie-Pierre (marie-pierre.gallasso@…) and some comments were from Rajan Joshi (rajanj@…)

In the specification text, in paragraph 8.5.3.2.2 Derivation process for luma motion vectors for merge mode, from step 1 to step 8, the merging candidates list is constructed without considering the value of use_integer_mv_flag. In step 9, the motion vector of candidate pointed by merge_idx is rounded if use_integer_mv_flag is equal to 1 before assignment to the current block. In HM, the motion vector of each candidate is rounded when use_integer_mv_flag is equal to 1, even the motion vector of the temporal candidate. So it can make a difference in 8.5.3.2.4 Derivation process for combined bi-predictive merging candidates, because in specification text, rounded and not rounded motion vectors may be combined.

In function getInterMergeCandidate() in TComDataCu.ccp (line 2631), merge candidates are derived one-by-one. When use_integer_mv flag is 1 or when the reference picture is the current picture, each candidate is converted to integer pel before storing it in pcMvFieldNeighbours. When processing the next merge candidate, there is a pruning step that checks whether the newly derived merge candidate is identical to an earlier one. This is accomplished using the function call hasEqualMotion().

if ( isAvailableB1 && (!isAvailableA1
!pcCULeft->hasEqualMotion( uiLeftPartIdx, pcCUAbove, uiAbovePartIdx ) ) )

The function hasEqualMotion() uses the original (non-rounded) motion vectors for comparison. So far, this behavior is exactly as in the spec, except that on the decoder side, there are a few mv rounding operations for unselected merge candidates, which has no normative impact. But later on, in case of bi-predictive merge, when selecting the combined merge candidates, there is a check for identical L0 and L1 motion vectors:

if (iRefPOCL0 == iRefPOCL1 && pcMvFieldNeighbours[(uiArrayAddr<<1)].getMv() == pcMvFieldNeighbours[(uiArrayAddr<<1)+1].getMv())

Here the check is performed on rounded motion vectors instead of original ones. Thus the software behaves inconsistently.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Note: See TracQuery for help on using queries.