ticket summary component version milestone type owner status created _changetime _description _reporter 207 VTM + 360Lib tries to read input/reference file even is E2E quality metrics are not enabled 360Lib defect new 2019-02-27T17:52:54+01:00 2019-02-27T17:52:54+01:00 "In the VTM codec initialization the method TExt360EncGop::initE2EMetricsCalc is not executed if SphereVideo is equal to 0. Therefore, the reference YUV file is not initialized. However, in the method below it is still access in the method TExt360EncGop::readOrigPicYuv as shown below. Void TExt360EncGop::calculatePSNRs(TComPic *pcPic) { #if SVIDEO_E2E_METRICS readOrigPicYuv(pcPic->getPOC()); reconstructPicYuv(pcPic->getPicYuvRec()); #endif [...] } Void TExt360EncGop::readOrigPicYuv(Int iPOC) { Int iDeltaFrames = iPOC*m_temporalSubsampleRatio - m_iLastFrmPOC; Int aiPad[2]={0,0}; m_pcTVideoIOYuvInputFile->skipFrames(iDeltaFrames, m_iInputWidth, m_iInputHeight, m_inputChromaFomat); PelUnitBuf tmpBuf; m_pcTVideoIOYuvInputFile->read(tmpBuf, *m_pcOrgPicYuv, IPCOLOURSPACE_UNCHANGED, aiPad, m_inputChromaFomat, false ); m_iLastFrmPOC = iPOC*m_temporalSubsampleRatio+1; } This leads to a segmentation fault, since we are trying to access initialized classes. This was detected using VTM3.0 + 360Lib8.0 but it is still in the trunk branch of 360Lib." jfmcarreira 1591 wrong bitstream and erroneous picheader values when Affine disabled and scaled reference (scalable or RPR) VTM defect new 2023-03-14T15:32:45+01:00 2023-03-14T15:32:45+01:00 "Encoder crashes and bitstream is not decodable for spatial scalibility multilayer when Affine is deactivated. PicHeader::m_maxNumAffineMergeCand (MaxNumSubblockMergeCand) depends on Affine flag and PicHeader::m_enableTMVPFlag, and is not correctly set." furban 1627 """Decoding process for palette mode"" does not say what to do with output samples" spec defect new 2024-01-25T10:29:07+01:00 2024-01-25T10:29:07+01:00 "Section 8.4.5.3 ""Decoding process for palette mode"" has an output of an array recSamples[ x ][ y ], but in each of the three places where this process is invoked there is no description of what to do with the output samples. I think the samples should probably be copied to a rectangle with either SLu, SCb, or SCr, and that the IsAvailable flag for the locations should be set. i.e. operations similar to those in 8.7.5.1. Also IbcVirBuf may need to be set if it is legal for intra block copy to reference palette mode decodes." peterderivaz 721 encoder crash for 444 coding of VTM master branch 360Lib defect new 2019-11-22T04:11:40+01:00 2019-11-22T04:11:40+01:00 "Encoder crashes for the VTM master branch s/w at the first frame of 444 YUV coding. The attached cfg files and command line can be used to duplicate the crash point: EncoderApp -c Map_444.cfg -c encoder_randomaccess_vtm.cfg -c classF.cfg -c yuv444.cfg If disabling the macro JVET_N0278_FIXES, the encoder can run but decoder still crashes." xyxiu 1530 --SPSNR_NN flag not responding 360Lib defect new 2022-02-02T01:30:25+01:00 2022-02-02T01:30:25+01:00 "Hi there, I'm trying to use 360Lib for end-to-end metrics. In my case input==output (no conversion). Adding the --SPSNR_NN flag doesn't add anything to the output. For what is worth, --SPSNR_I adds relevant columns so I'm wondering if it's a specific issue for --SPSNR_NN. Is it possible I'm making a mistake here? Any help much appreciated. " char-tan 1609 NoBackwardPredFlag derivation ambiguity spec defect new 2023-08-17T16:44:58+02:00 2023-08-17T16:44:58+02:00 "8.3.6 derivation of NoBackwardPredFlag is as below: - If DiffPicOrderCnt( aPic, currPic ) is less than or equal to 0 for each active picture aPic in RefPicList0 '''or''' RefPicList1 of the current slice, NoBackwardPredFlag is set equal to 1. - Otherwise, NoBackwardPredFlag is set equal to 0. '''or''' seems somewhat ambiguous here. It could be interpreted that if the DiffPicOrderCnt condition is valid for either L0 or L1 list then you should set NoBackwardPredFlag to 1. Using '''and''' seems to make the meaning more unambiguous." swarrington 1618 [Multilayer Profiles] Potential Mismatch of VTM22.0 & Specification Related To Derivation Process For Merge Motion Vector Difference spec defect new 2023-10-17T15:33:23+02:00 2023-10-17T15:35:22+02:00 "In ""8.5.2.7 Derivation process for merge motion vector difference"", Equation 563: mMvdL1[ 0 ] = Sign( currPocDiffL0 ) == Sign( currPocDiffL1 ) ? mMvdL0[ 0 ] : −mMvdL0[ 0 ]. The equivalent code is in VTM22.0, InterPrediction.cpp, MergeCtx::getMmvdDeltaMv(), starting from line 2478: if ((poc1 - currPoc)*(poc0 - currPoc) > 0) { deltaMv[1] = deltaMv[0]; } else { deltaMv[1].set(-1 * deltaMv[0].getHor(), -1 * deltaMv[0].getVer()); } According to specification, definition of Sign(x): Sign(x) = 1; x > 0 Sign(x) = 0; x == 0 Sign(x) = -1; x < 0 Let's assume: - result of condition below in specification as r_spec: r_spec = Sign( currPocDiffL0 ) == Sign( currPocDiffL1 ) - result of condition below in VTM22.0 as r_vtm: r_vtm = (currPocDiffL1 * currPocDiffL0 > 0) Use combination of currPocDiffL0 & currPocDiffL1 as input: 1.) (currPocDiffL0 < 0) && (currPocDiffL1 < 0) r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm; 2.) (currPocDiffL0 < 0) && (currPocDiffL1 > 0) r_spec = 0; r_vtm = 0; ==> r_spec == r_vtm; 3.) (currPocDiffL0 > 0) && (currPocDiffL1 < 0) r_spec = 0; r_vtm = 0; ==> r_spec == r_vtm; 4.) (currPocDiffL0 < 0) && (currPocDiffL1 < 0) r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm; 5.) (currPocDiffL0 == 0) && (currPocDiffL1 != 0) r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm; 6.) (currPocDiffL0 != 0) && (currPocDiffL1 == 0) r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm; 7.) (currPocDiffL0 == 0) && (currPocDiffL1 == 0) r_spec = 1; r_vtm = 0; ==> r_spec != r_vtm; Case 5, 6 & 7 are only possible in multilayer profile (current picture and reference picture same POC, but different layers). As shown above, for case 7, results of specification & VTM are different. So, which is the correct one? specification or VTM?" ksthey 1619 [Multilayer Profiles] Potential Mismatch of VTM22.0 & Specification Related To Derivation Process For Merge Motion Vector Difference VTM defect new 2023-10-25T09:05:58+02:00 2023-10-25T09:05:58+02:00 "In ""8.5.2.7 Derivation process for merge motion vector difference"", Equation 563: mMvdL1[ 0 ] = Sign( currPocDiffL0 ) == Sign( currPocDiffL1 ) ? mMvdL0[ 0 ] : −mMvdL0[ 0 ]. The equivalent code is in VTM22.0, InterPrediction.cpp, MergeCtx::getMmvdDeltaMv(), starting from line 2478: if ((poc1 - currPoc)*(poc0 - currPoc) > 0) { deltaMv[1] = deltaMv[0]; } else { deltaMv[1].set(-1 * deltaMv[0].getHor(), -1 * deltaMv[0].getVer()); } According to specification, definition of Sign(x): Sign(x) = 1; x > 0 Sign(x) = 0; x == 0 Sign(x) = -1; x < 0 Let's assume: Result of condition below in specification as r_spec: r_spec = Sign( currPocDiffL0 ) == Sign( currPocDiffL1 ) Result of condition below in VTM22.0 as r_vtm: r_vtm = ((poc1 - currPoc)*(poc0 - currPoc) > 0) Use combination of currPoc, poc0 & poc1 below as inputs: 1.) currPoc: 1, poc0: 0, poc1: 0 r_spec = 1; r_vtm = 1; 2.) currPoc: 1, poc0: 0, poc1: 2 r_spec = 0; r_vtm = 0; 3.) currPoc: 1, poc0: 2, poc1: 0 r_spec = 0; r_vtm = 0; 4.) currPoc: 1, poc0: 2, poc1: 2 r_spec = 1; r_vtm = 1; 5.) currPoc: 1, poc0: 1, poc1: 0 r_spec = 1; r_vtm = 1; 6.) currPoc: 1, poc0: 0, poc1: 1 r_spec = 1; r_vtm = 1; 7.) currPoc: 1, poc0: 1, poc1: 1 r_spec = 1; r_vtm = 0; Case 5, 6 & 7 are only possible in multilayer profiles (current picture and reference picture same POC, but different layers). As shown above, for case 7, results of specification & VTM are different. So, which is the correct one? specification or VTM?" ksthey 1620 Parcat not dropping prefix_sei NAL units for IDR pictures of non-first parallel segments VTM defect new 2023-10-31T23:36:22+01:00 2023-10-31T23:36:22+01:00 "When using parcat to create a sequence-level bitstream from a collection of segment-level bitstreams, it was found that the prefix_sei NAL unit for the IDR picture of each segment was being retained, whereas for segments other than the first one they should be dropped. This leads to redundant prefix_sei NAL units in the sequence-level bitstream. See the attachment for a suggested fix." crosewarne 1624 Incorrect indexing in computation of motion vector offset spec defect new 2024-01-24T17:49:08+01:00 2024-01-24T17:49:08+01:00 "In the decoding process for inter blocks (8.5.6.1) there are three places where the expression refMvLX[ xSbIdx ][ xSbIdx ] is used. I believe these should be replaced by refMvLX[ xSbIdx ][ ySbIdx ]. (This applies to ""ITU-T H.266 (V3) (09/2023)"" but I couldn't find an appropriate version in the dropdown.)" peterderivaz 1629 mtt_split_cu_vertical_flag context uses undefined variable chType spec defect new 2024-01-25T11:46:56+01:00 2024-01-25T11:46:56+01:00 "The context derivation for mtt_split_cu_vertical_flag says it has an input of ""the dual tree channel type chType"" but it is not clear where this comes from. mtt_split_cu_vertical_flag is read in the coding tree syntax which does not mention chType. chType is mentioned in a different clause (the coding unit syntax), but it seems unlikely this is the value to be used because it has an apparent dependency on mtt_split_cu_vertical_flag via: 1. mtt_split_cu_vertical_flag is used to compute MttSplitMode 2. MttSplitMode is used to compute ModeTypeCondition 3. ModeTypeCondition is used to compute modeType 4. modeType is used to compute treeType 5. treeType is used to compute chType. What value should be used for chType when reading the mtt_split_cu_vertical_flag syntax element? " peterderivaz 1630 Missing equations for applying AmvrShift spec defect new 2024-01-25T12:15:40+01:00 2024-01-25T12:15:40+01:00 "In the semantics for amvr_precision_idx, some motion vectors are adjusted as follows: {{{ Otherwise (inter_affine_flag[ x0 ][ y0 ] is equal to 1), the variables MvdCpL0[ x0 ][ y0 ][ 0 ][ 0 ], MvdCpL0[ x0 ][ y0 ][ 0 ][ 1 ], MvdCpL0[ x0 ][ y0 ][ 1 ][ 0 ], MvdCpL0[ x0 ][ y0 ][ 1 ][ 1 ], MvdCpL0[ x0 ][ y0 ][ 2 ][ 0 ] and MvdCpL0[ x0 ][ y0 ][ 2 ][ 1 ] are modified as follows: MvdCpL0[ x0 ][ y0 ][ 0 ][ 0 ] = MvdCpL0[ x0 ][ y0 ][ 0 ][ 0 ] << AmvrShift (165) MvdCpL1[ x0 ][ y0 ] [ 0 ][ 1 ] = MvdCpL1[ x0 ][ y0 ][ 0 ][ 1 ] << AmvrShift (166) MvdCpL0[ x0 ][ y0 ][ 1 ][ 0 ] = MvdCpL0[ x0 ][ y0 ][ 1 ][ 0 ] << AmvrShift (167) MvdCpL1[ x0 ][ y0 ] [ 1 ][ 1 ] = MvdCpL1[ x0 ][ y0 ][ 1 ][ 1 ] << AmvrShift (168) MvdCpL0[ x0 ][ y0 ][ 2 ][ 0 ] = MvdCpL0[ x0 ][ y0 ][ 2 ][ 0 ] << AmvrShift (169) MvdCpL1[ x0 ][ y0 ] [ 2 ][ 1 ] = MvdCpL1[ x0 ][ y0 ][ 2 ][ 1 ] << AmvrShift (170) }}} Note that the description says that 6 locations in the array MvdCpL0 are modified, while the equations modify 3 locations in the array MvdCpL0 and 3 locations in the array MvdCpL1. I wonder if both the description and the equations are incomplete, and the correct thing to do is to modify the 6 locations in the array MvdCpL0 and also the same 6 locations in the array MvdCpL1? " peterderivaz 1631 "Should ""Motion vector storing process for geometric partitioning mode"" store HpelIfIdx?" spec defect new 2024-01-25T12:35:06+01:00 2024-01-25T12:35:06+01:00 "In the General clause of ""Decoding process for inter blocks"", the array HpelIfIdx is written at the same time as other motion vector information is stored: {{{ MvL0[ xSb + x ][ ySb + y ] = mvL0[ xSbIdx ][ ySbIdx ] (887) MvL1[ xSb + x ][ ySb + y ] = mvL1[ xSbIdx ][ ySbIdx ] (888) MvDmvrL0[ xSb + x ][ ySb + y ] = refMvL0[ xSbIdx ][ ySbIdx ] (889) MvDmvrL1[ xSb + x ][ ySb + y ] = refMvL1[ xSbIdx ][ ySbIdx ] (890) RefIdxL0[ xSb + x ][ ySb + y ] = refIdxL0 (891) RefIdxL1[ xSb + x ][ ySb + y ] = refIdxL1 (892) PredFlagL0[ xSb + x ][ ySb + y ] = predFlagL0[ xSbIdx ][ ySbIdx ] (893) PredFlagL1[ xSb + x ][ ySb + y ] = predFlagL1[ xSbIdx ][ ySbIdx ] (894) HpelIfIdx[ xSb + x ][ ySb + y ] = hpelIfIdx (895) BcwIdx[ xSb + x ][ ySb + y ] = bcwIdx (896) }}} However, in the ""Motion vector storing process for geometric partitioning mode"", HpelIfIdx is not written: {{{ MvL0[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = mvL0 (1045) MvL1[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = mvL1 (1046) MvDmvrL0[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = mvL0 (1047) MvDmvrL1[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = mvL1 (1048) RefIdxL0[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = refIdxL0 (1049) RefIdxL1[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = refIdxL1 (1050) PredFlagL0[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = predFlagL0 (1051) PredFlagL1[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = predFlagL1 (1052) BcwIdx[ ( xSbIdx << 2 ) + x ][ ( ySbIdx << 2 ) + y ] = 0 (1053) }}} As far as I can understand, I think it is possible for these unspecified HpelIfIdx values to affect the decoding process?" peterderivaz 1632 Incorrect indexing used for choosing matrix intra sample prediction spec defect new 2024-01-25T12:47:08+01:00 2024-01-25T12:47:08+01:00 "Clause 8.4.5.2.1 reads: {{{ Inputs to this process are: – a sample location ( xTbCmp, yTbCmp ) specifying the top-left sample of the current transform block relative to the top-left sample of the current picture, ... if MipChromaDirectFlag[ xTbCmp ][ yTbCmp ] is equal to 1 and cIdx is not equal to 0, }}} This looks up values in MipChromaDirectFlag based on counts of chroma samples. However, when MipChromaDirectFlag is derived, the indexing is done based on counts of luma samples: {{{ Derivation process for chroma intra prediction mode Input to this process are: – a luma location ( xCb, yCb ) specifying the top-left sample of the current chroma coding block relative to the top-left luma sample of the current picture, ... In this process, the chroma intra prediction mode IntraPredModeC[ xCb ][ yCb ] and the MIP chroma direct mode flag MipChromaDirectFlag[ xCb ][ yCb ] are derived. }}} I think this can be fixed by changing 8.4.5.2.1 to use ""MipChromaDirectFlag[ xTbCmp * SubWidthC ][ yTbCmp * SubHeightC ]"" instead of ""MipChromaDirectFlag[ xTbCmp ][ yTbCmp ]""." peterderivaz 1634 Matrices QStateTransTable,levelScale,AlfFixFiltCoeff,AlfClassToFiltMap are incorrectly transposed spec defect new 2024-01-25T13:54:17+01:00 2024-01-25T13:54:17+01:00 "The spec defines the ordering of indices in a matrix and initialization syntax in 5.10. However, the matrices QStateTransTable (7.4.12.11), levelScale (in 8.7.3), AlfFixFiltCoeff (7.4.3.18), AlfClassToFiltMap (7.4.3.18) do not follow this ordering, but instead use C based ordering (i.e. they are transposed). For example, {{{ The array QStateTransTable[ ][ ] is specified as follows: QStateTransTable[ ][ ] = { { 0, 2 }, { 2, 0 }, { 1, 3 }, { 3, 1 } } }}} This could be fixed either by transposing the matrices in the spec, i.e. {{{ QStateTransTable = { {0, 2, 1, 3}, {2, 0, 3, 1} } }}} or by swapping the indices when it is accessed, i.e. changing things like {{{QState = QStateTransTable[ QState ][ AbsLevel[ xC ][ yC ] & 1 ]}}} to {{{QState = QStateTransTable[ AbsLevel[ xC ][ yC ] & 1 ][ QState ]}}} " peterderivaz 1635 Incorrect inference for tu_y_coded_flag spec defect new 2024-01-25T14:08:39+01:00 2024-01-25T14:08:39+01:00 "tu_y_coded_flag is used in clause 8.8.3.5 to choose the boundary filtering strength used in the deblocking filter. When tu_y_coded_flag is not present, the inference rules in clause 7.4.12.10 say: {{{ When tu_y_coded_flag[ x0 ][ y0 ] is not present and treeType is not equal to DUAL_TREE_CHROMA, its value is inferred as follows: – If cu_sbt_flag is equal to 1 and one of the following conditions is true, tu_y_coded_flag[ x0 ][ y0 ] is inferred to be equal to 0: – subTuIndex is equal to 0 and cu_sbt_pos_flag is equal to 1; – subTuIndex is equal to 1 and cu_sbt_pos_flag is equal to 0. – Otherwise, tu_y_coded_flag[ x0 ][ y0 ] is inferred to be equal to 1. }}} I think this is missing some cases that should infer 0. For example, if cu_coded_flag is equal to 0, then no transform_tree structure will be present, and tu_y_coded_flag will be inferred equal to 1 according to the spec. However, I believe the deblocking in the VTM works as if tu_y_coded_flag was inferred equal to 0 in this case. " peterderivaz 1628 "Derivation of ModeTypeCondition should say ""one or more""" spec defect new 2024-01-25T10:38:02+01:00 2024-01-25T10:38:02+01:00 "The derivation of ModeTypeCondition reads: {{{ The variable ModeTypeCondition is derived as follows: If one or more of the following conditions are true, ModeTypeCondition is set equal to 0: – sh_slice_type is equal to I and sps_qtbtt_dual_tree_intra_flag is equal to 1; – modeTypeCurr is not equal to MODE_TYPE_ALL; – sps_chroma_format_idc is equal to 0; – sps_chroma_format_idc is equal to 3; – Otherwise, if one or more of the following conditions is true, ModeTypeCondition is set equal to 1: – cbWidth * cbHeight is equal to 64 and split_qt_flag is equal to 1; – cbWidth * cbHeight is equal to 64 and split_qt_flag is equal to 0 and MttSplitMode[ x0 ][ y0 ][ mttDepth ] is equal to SPLIT_TT_HOR or SPLIT_TT_VER; – cbWidth * cbHeight is equal to 32 and MttSplitMode[ x0 ][ y0 ][ mttDepth ] is equal to SPLIT_BT_HOR or SPLIT_BT_VER; – Otherwise, if one of the following conditions is true, ModeTypeCondition is set equal to 1 + ( sh_slice_type != I ? 1 : 0 ): – cbWidth * cbHeight is equal to 64 and MttSplitMode[ x0 ][ y0 ][ mttDepth ] is equal to SPLIT_BT_HOR or SPLIT_BT_VER and sps_chroma_format_idc is equal to 1; – cbWidth * cbHeight is equal to 128 and MttSplitMode[ x0 ][ y0 ][ mttDepth ] is equal to SPLIT_TT_HOR or SPLIT_TT_VER and sps_chroma_format_idc is equal to 1; – cbWidth is equal to 8 and MttSplitMode[ x0 ][ y0 ][ mttDepth ] is equal to SPLIT_BT_VER; – cbWidth is equal to 16 and split_qt_flag is equal to 0 and MttSplitMode[ x0 ][ y0 ][ mttDepth ] is equal to SPLIT_TT_VER; – Otherwise, ModeTypeCondition is set equal to 0. }}} The ""if one of the following conditions is true"" should read ""if one or more of the following conditions is true"". This can cause decoding differences for legal bitstreams. For example, cbWidth = 16, cbHeight = 8, MttSplitMode[ x0 ][ y0 ][ mttDepth ] = SPLIT_TT_VER, sps_chroma_format_idc = 1, split_qt_flag = 0. In this case, two of the conditions can be true at the same time. " peterderivaz 1594 Mismatch between VVC spec and VTM for sample generation in CCLM process spec H.266/VVC v2 defect new 2023-04-14T22:34:56+02:00 2023-07-16T19:40:38+02:00 "The ticket is about the text in the VVC spec in section 8.4.5.2.14 on pages 226 and 227, just after the equation 359. The text after eqn 359 in the spec should be updated to make it clear that luma samples prior to the in-loop filtering process are being used; and not luma samples prior to the deblocking filter. Specifically, in the text from the spec, the ""prior to the deblocking filter"" should be changed to ""prior to the in-loop filter process"" at three places in the spec. On checking the software code, the samples prior to the in-loop filter process are being used. But the spec mentions prior to the deblocking filter. Suggestion is to update this. As an aside, the text preceding eqn. 316 lists: The refW + refH + 1 + ( 2 * refIdx ) neighbouring samples refUnfilt[ x ][ y ] that are constructed samples prior to the inloop filter process, ... which seems the correct way to describe the text following eqn 359 (note: text near eqn. 316 seems correct, no issues in that). Text following eqn. 359: 1. The collocated luma samples pY[ x ][ y ] with x = 0..nTbW * SubWidthC − 1, y= 0..nTbH * SubHeightC − 1 are set equal to the reconstructed luma samples prior to the deblocking filter process at the locations ( xTbY + x, yTbY + y ). 2. The neighbouring luma samples pY[ x ][ y ] are derived as follows: – When availL is equal to TRUE, the neighbouring luma samples pY[ x ][ y ] with x = −3..−1, y = ( availT ? −1 : 0 )..SubHeightC * Max( nTbH, numSampL ) − 1, are set equal to the reconstructed luma samples prior to the deblocking filter process at the locations ( xTbY + x, yTbY +y ). – When availT is equal to FALSE, the neighbouring luma samples pY[ x ][ y ] with x = −2..SubWidthC * nTbW − 1, y = −2..−1, are set equal to the luma samples pY[ x ][ 0 ] – When availT is equal to TRUE, the neighbouring luma samples pY[ x ][ y ] with x = ( availL ? −1 : 0 )..SubWidthC * Max( nTbW, numSampT ) − 1, y = −3..−1, are set equal to the reconstructed luma samples prior to the deblocking filter process at the locations ( xTbY+ x, yTbY + y ). – When availL is equal to FALSE, the neighbouring luma samples pY[ x ][ y ] with x = −1, y = −2..SubHeightC * nTbH − 1, are set equal to the reconstructed luma samples pY[ 0 ][ y ]." ankur 1607 Wrong sign (+ instead of -) in Fig 16 Flowchart for decoding a decision in the ITU text spec H.266/VVC v2 defect new 2023-07-18T09:31:26+02:00 2023-07-18T09:31:26+02:00 "In Figure 16 - Flowchart for decoding a decision of the ITU text there is a wrong sign while the ISO text is correct: ivlOffset = ivlOffset + ivlCurrRange should be ivlOffset = ivlOffset – ivlCurrRange " bbross 1617 Not initialized NumCtusInSlice[0] to 0. spec H.266/VVC v2 defect new 2023-09-26T03:21:54+02:00 2023-09-26T03:21:54+02:00 "In VVC V2 6.5.1, NumCtusInSlice[0] = 0 is missing. if( pps_single_slice_per_subpic_flag ) { if( !sps_subpic_info_present_flag ) /* There is no subpicture info and only one slice in a picture. */ for( j = 0; j < NumTileRows; j++ ) for( i = 0; i < NumTileColumns; i++ ) AddCtbsToSlice( 0, TileColBdVal[ i ], TileColBdVal[ i + 1 ], TileRowBdVal[ j ], TileRowBdVal[ j + 1 ] ) should be replaced by if( pps_single_slice_per_subpic_flag ) { if( !sps_subpic_info_present_flag ) /* There is no subpicture info and only one slice in a picture. */ NumCtusInSlice[0] = 0 for( j = 0; j < NumTileRows; j++ ) for( i = 0; i < NumTileColumns; i++ ) AddCtbsToSlice( 0, TileColBdVal[ i ], TileColBdVal[ i + 1 ], TileRowBdVal[ j ], TileRowBdVal[ j + 1 ] )" djpark0115 1376 Decoder crash in decoding a multiple CVS bitstream VTM VTM-10.0 defect new 2020-09-09T17:03:22+02:00 2020-09-09T19:38:06+02:00 "Attached is a bitstream containing two CVS. It was generated by concatenating a two-layer spatial scalable bitstream with a two-layer SNR scalable bitstream. Both scalable bitstreams were encoded with VTM10.0. When decode this two-CVS bitstream, the VTM10.0 decoder could correctly decode the first CVS but has problem in decoding the second CVS. If run the decoder on this bitstream multiple times, the decoder may show different behaviors when start decoding the second CVS. Sometimes it crashes with the error message ""Slice.h:1671: Invalid chroma format parameter"", sometimes it crashes without any message, and sometimes it could successfully decode the second CVS. " rickxu 1077 Enabling dependent quantization for lossy slices in mixed lossy-lossless VTM VTM-10.0 enhancement new 2020-05-20T23:29:51+02:00 2020-09-09T19:39:35+02:00 "When enabling dependent quantization in the config file for mix of lossy and lossless slices ""cfg\lossless\lossless_mixed.cfg"", dependent quantization is turned on at SPS level only but not used in any of the slices. The desired behavior would be that dependent quantization is enabled in lossy slices (but disabled in lossless slices) when DepQuant is set equal to 1 in the config file." jonatan 1392 MaxCUWidth and MaxCUHeight config parameters VTM VTM-10.0 enhancement new 2020-09-30T11:29:17+02:00 2020-09-30T11:29:17+02:00 "MaxCUWidth and MaxCUHeight encoder configuration parameters don't seem to have effect even though present in the default VTM configuration files. It looks like the functionality of these two is overwritten by the CTUSize parameter. MaxCUWidth is however referred to if compiling VTM with ENABLE_QPA_SUB_CTU set to 0, but probably the same functionality could be achieved using CTUSize instead. There is comment relating to CTUSize parameter saying: ""specifies the CTU size if QTBT is on"". That may indicate the MaxCUWidth and MaxCUHeight parameters are leftovers from pre-QTBT time. Or are those still intended to be used if disabling some QTBT functionality?" jani.lainema 1430 Cannot set MTT depth equal to 0 in VTM (Unnecessary encoder config check?) VTM VTM-10.0 enhancement new 2020-11-19T11:51:13+01:00 2021-04-20T01:13:42+02:00 "Hi experts, It seems we cannot set MTT depth equal to 0 in VTM with --MaxMTTHierarchyDepth=0 --MaxMTTHierarchyDepthISliceL=0 --MaxMTTHierarchyDepthISliceC=0 Comment out the following checks resolved this issue. If the comment out is unnecessary, I'd suggest to remove it. +#if 0 if (m_uiMaxMTTHierarchyDepthI == 0) { xConfirmPara(m_uiMaxBT[0] != m_uiMinQT[0], ""MaxBTLumaISlice shall be equal to MinQTLumaISlice when MaxMTTHierarchyDepthISliceL is 0.""); xConfirmPara(m_uiMaxTT[0] != m_uiMinQT[0], ""MaxTTLumaISlice shall be equal to MinQTLumaISlice when MaxMTTHierarchyDepthISliceL is 0.""); } if (m_uiMaxMTTHierarchyDepthIChroma == 0) { xConfirmPara(m_uiMaxBT[2] != (m_uiMinQT[2] << (int)getChannelTypeScaleX(CHANNEL_TYPE_CHROMA, m_chromaFormatIDC)), ""MaxBTChromaISlice shall be equal to MinQTChromaISlice when MaxMTTHierarc\ hyDepthISliceC is 0.""); xConfirmPara(m_uiMaxTT[2] != (m_uiMinQT[2] << (int)getChannelTypeScaleX(CHANNEL_TYPE_CHROMA, m_chromaFormatIDC)), ""MaxTTChromaISlice shall be equal to MinQTChromaISlice when MaxMTTHierarc\ hyDepthISliceC is 0.""); } if (m_uiMaxMTTHierarchyDepth == 0) { xConfirmPara(m_uiMaxBT[1] != m_uiMinQT[1], ""MaxBTNonISlice shall be equal to MinQTNonISlice when MaxMTTHierarchyDepth is 0.""); xConfirmPara(m_uiMaxTT[1] != m_uiMinQT[1], ""MaxTTNonISlice shall be equal to MinQTNonISlice when MaxMTTHierarchyDepth is 0.""); } #endif Without the above changes, the following error occured when MTT depth equal to 0. Error: MaxBTChromaISlice shall be equal to MinQTChromaISlice when MaxMTTHierarchyDepthISliceC is 0. Error: MaxTTChromaISlice shall be equal to MinQTChromaISlice when MaxMTTHierarchyDepthISliceC is 0. Error: MaxTTNonISlice shall be equal to MinQTNonISlice when MaxMTTHierarchyDepth is 0. Even if we fix encoder settings as below as the above error msg suggested, --MaxBTChromaISlice=4 --MaxTTChromaISlice=4 --MaxTTNonISlice=8 We have another errors, which should be contradicted with each other. Error: Maximum BT size for chroma block in I slice should be larger than minimum QT size Error: Maximum TT size for chroma block in I slice should be larger than minimum QT size If something is missed, please let me know. There could be easy way to set MTT depth equal to 0, which I couldn't find in short time. " Tomohiro Ikai 1391 Unnecessary setting of mrgTypeNeighbours in getInterMergeCandidates() and checking condition in getInterMMVDMergeCandidates() VTM VTM-10.0 VTM-10.1 enhancement new 2020-09-30T04:23:10+02:00 2021-04-20T00:59:52+02:00 "The unnecessary setting of mrgTypeNeighbours in PU::getInterMergeCandidates() should be removed. {{{ void PU::getInterMergeCandidates() { if ( mrgCtx.interDirNeighbours[uiArrayAddr] == 1 && pu.cs->slice->getRefPic(REF_PIC_LIST_0, mrgCtx.mvFieldNeighbours[uiArrayAddr << 1].refIdx)->getPOC() == pu.cs->slice->getPOC()) { mrgCtx.mrgTypeNeighbours[uiArrayAddr] = MRG_TYPE_IBC; } } }}} Since the merge types for all merge candidates for MMVD are MRG_TYPE_DEFAULT_N, the unnecessary checking condition in PU::getInterMMVDMergeCandidates() should be removed. {{{ void PU::getInterMMVDMergeCandidates() { for (k = 0; k < maxNumMergeCand; k++) { if (mrgCtx.mrgTypeNeighbours[k] == MRG_TYPE_DEFAULT_N) { refIdxList0 = mrgCtx.mvFieldNeighbours[(k << 1)].refIdx; refIdxList1 = mrgCtx.mvFieldNeighbours[(k << 1) + 1].refIdx; ... } } } }}}" wangyang.cs 1434 The xEncodeInterResidualQT() function seem to be error VTM VTM-10.2 defect new 2020-11-24T10:20:31+01:00 2020-11-24T10:20:31+01:00 When CuWidth/CuHeight are 128 and TuWidth/TuHeight are 64, Cbf of Chroma are written five times and Cbf of Luma are written four times in xEncodeInterResidualQT(), but Cbf of Chroma are written four times and cbf of Luma are written four times in transform_unit(). In xEncodeInterResidualQT(), Chroma Cbf are written when currDepth is 0. annci 1482 static Rom g_Rom is not free VTM VTM-12.0 defect new 2021-04-22T10:57:49+02:00 2022-04-21T12:57:09+02:00 "source/Lib/CommonLib/DepQuant.cpp:338 static Rom g_Rom; There is no free for static Rom g_Rom, which will cause segment fault if I write an another encoderApp and encode some video multiple times. I haven't read the context, but uninitiate it manually could fix it. {{{ diff --git a/source/Lib/CommonLib/DepQuant.cpp b/source/Lib/CommonLib/DepQuant.cpp index 2e914d0b..6e625b15 100644 --- a/source/Lib/CommonLib/DepQuant.cpp +++ b/source/Lib/CommonLib/DepQuant.cpp @@ -132,6 +132,7 @@ namespace DQIntern Rom() : m_scansInitialized(false) {} ~Rom() { xUninitScanArrays(); } void init () { xInitScanArrays(); } + void uninit () { xUninitScanArrays(); } const NbInfoSbb* getNbInfoSbb( int hd, int vd ) const { return m_scanId2NbInfoSbbArray[hd][vd]; } const NbInfoOut* getNbInfoOut( int hd, int vd ) const { return m_scanId2NbInfoOutArray[hd][vd]; } const TUParameters* getTUPars ( const CompArea& area, const ComponentID compID ) const @@ -1590,6 +1591,7 @@ DepQuant::DepQuant( const Quant* other, bool enc ) : QuantRDOQ( other ) DepQuant::~DepQuant() { + DQIntern::g_Rom.uninit(); delete static_cast(p); } }}}" spartazhc 1483 /cfg/444/yuv444.cfg seems obsolete VTM VTM-12.0 enhancement new 2021-04-26T15:25:53+02:00 2021-04-26T15:25:53+02:00 "/cfg/444/yuv444.cfg enables BDPCM and doesn't include anything else. This is confusing as not all YUV 4:4:4 CTC configurations enable BDPCM. In addition, for those CTC configurations where BDPCM is enabled there are specific cfg files available (e.g. /cfg/per-class/classSCC.cfg). Seems like /cfg/444/yuv444.cfg (and the /cfg/444/ directory) are left-overs from some earlier time and can be deleted to avoid confusion." jani.lainema 1484 /cfg/per-class/formatRGB.cfg is silent on colorspace conversion VTM VTM-12.0 enhancement new 2021-04-26T15:38:57+02:00 2021-04-26T15:38:57+02:00 "Common test conditions for RGB content request RGB to GBR conversion to be used. However, /cfg/per-class/formatRGB.cfg is not doing that. It seems the feature is ""hidden"" in the sequence specific configuration files. This is confusing as it is really a class/format based option instead of something related to a specific sequence. It is suggested to include the RGB to GBR conversion related parameters to /cfg/per-class/formatRGB.cfg: InputColourSpaceConvert : RGBtoGBR SNRInternalColourSpace : 1 OutputInternalColourSpace : 0 " jani.lainema 1588 VTM is also affected. While testing the VVC in lossless mode, encoder seems to generate a invalid bit-stream and the decoder fails with error message VTM VTM-17.2 defect new 2023-01-18T12:55:41+01:00 2023-01-18T18:04:25+01:00 "- The idea is to run VVC Software in lossless mode. - Was able to set up VVC locally and provided appropriate configuration files to run it in lossless mode. - However, the encoder seems to generate an invalid bitstream and the decoder fails with the following error message: {{{ Warning: Level set to none, invalid or unknown value POC 0 LId: 0 TId: 0 ( IDR_N_LP, I-SLICE, QP 0 ) [DT 0.005] [L0] [L1] [:,(unk)] Total Time: 0.104 sec. }}} - See attachments for configuration files, log results, and a sample image to reproduce the issue Steps to Reproduce: - Download the attached configuration files (lossless.cfg, encoder_intra_vtm.cfg), the sample image (cim10_672x768_crop.ppm) - Download and run the attached batch file (00_test_VVC.bat) - %ENC% -i tmp.raw -c encoder_intra_vtm.cfg -c lossless.cfg --SourceWidth=!width! --SourceHeight=!height! --BitstreamFile=!out! -f 1 -fr 1 -g 1 >> %resE% - %DEC% --BitstreamFile=!out! --ReconFile=!recon! -opl logDec.txt >> %resD% - The encoder and decoder log files are attached for reference" Shabhrish 1582 Decoder crash with IDR refresh VTM VTM-18.2 defect new 2022-12-02T13:44:03+01:00 2022-12-02T13:44:03+01:00 "The following encoder call produces a decodable bitstream but with an invalid reference picture. In the decoder with ""checkRPL"" the temporalIds of the referencing and the reference picture are checked. Here, the temporalId of the reference picture is higher than the one referencing it. ERROR: In function ""checkRPL"" in /Users/bartnik/git/vgit_VVCSoftware_VTM/source/Lib/CommonLib/Slice.cpp:754: The picture referred to by each active entry in RefPicList[ 0 ] or RefPicList[ 1 ] shall be present in the DPB and shall have TemporalId less than or equal to that of the current picture. configuration: RA, DecodingRefreshType=2, IntraPeriod=64 encoder call: EncoderApp -c encoder_randomaccess_vtm.cfg -c per-sequence/RaceHorses.cfg --DecodingRefreshType=2 -ip 64 -f 65" c.bartnik 1590 Issue with sub-picture functionality VTM VTM-18.2 defect new 2023-02-24T08:07:27+01:00 2023-07-12T14:36:29+02:00 "I would like to bring to your attention an issue we are facing in our MPEG Immersive video (MIV) experiments related to the VTM project. Our experiments involve splitting atlases into sub-pictures and encoding them separately with VTM. We then merge them using the VTM sub-picture merging tool. However, we have encountered a problem where there is an offset in rendering from the second frame onwards. After investigating, we have identified that this issue is due to incorrect decoding of the merged bitstream. We suspect that this is a bug in the VTM merge application or in the VTM decoder. I would like to provide more detailed information on our findings, which can be found in MPEG input contribution m61912 '[MIV] Preliminary experimental result of EE7'. Here is the link to the document: https://dms.mpeg.expert/doc_end_user/current_document.php?id=85697&id_meeting=193. A detailed discussion on this issue within MIV Ahg is available here: https://mpeg.expert/software/MPEG/MIV/InputDocuments/-/issues/652. Additionally, we would like to provide the VVC bitstream to recreate this situation and investigate the issue further." vulcano 1595 decoding error when generating multilayer bitstream Conformance VTM-19.0 defect new 2023-04-16T05:52:50+02:00 2023-04-17T17:18:27+02:00 "VTM decoder cannot correctly decode multilayer bitstream that is generated by unmodified VTM encoder (with config. changes). Related conformance bitstreams: OLS_A_Tencent_5 (bitstream as well as cfg files attached) OLS_B_Tencent_5 (encoder exit without a message, cfg files attached) OLS_C_Tencent_5 (encoder exit without a message, cfg files attached) This bug report may be related to #1581. VTM version: VTM-20.0 Commandline for OLS_A_Tencent_5: EncoderApp.exe -c encoder_lowdelay_P_vtm.cfg -c two_layers_wo_ILP.cfg -c RaceHorses.cfg Decoder error message: ERROR: In function ""DecLib::xDecodeSlice"" in C:\Work\JVET\Conformance\VVCSoftware_VTM-VTM-20.0\source\Lib\DecoderLib\DecLib.cpp:2829: All slices in OlsInScope shall have the same value of nuh_layer_id when ptl_multilayer_enabled_flag is equal to 0 Commandline for OLS_B_Tencent_5: EncoderApp.exe -c encoder_lowdelay_P_vtm.cfg -c two_layers_w_ILP.cfg -c RaceHorses.cfg Commandline for OLS_C_Tencent_5: EncoderApp.exe -c encoder_lowdelay_P_vtm.cfg -c three_layers_w_ILP.cfg -c RaceHorses.cfg " xiaozhongxu 1144 Seg fault in several compliance check when RPL is sent and is not empty in IDR VTM VTM-19.0 defect new 2020-06-25T16:12:59+02:00 2023-01-11T09:12:50+01:00 "When sps_idr_rpl_present_flag == 1, and num_ref_entries[][] != 0 on an IDR, the compliance checks in checkCRA(), checkRPL() and checkSubpicTypeConstraints() try to access reference picture already remove in rcListPic, and cause a segmentation fault. Indeed, this list is flushed on IDR just after reading the nal_unit_header." forayr 1585 Enocoder check for invalid NNPF SEI combination missing VTM VTM-19.0 defect new 2023-01-08T16:22:36+01:00 2023-01-08T16:22:36+01:00 "Due to the problem with the the NNPF characteristics SEI example config file reported in #1585 I ran the encoder with {{{-c ../cfg/sei_vui/neural_network_post_filter_activation.cfg}}} only. The encoder ran without problems, but the decoder reported {{{ ERROR: In function ""xReadSEImessage"" in source/Lib/DecoderLib/SEIread.cpp:454: At leaset one NNPFC SEI message should precede NNPFA }}} indicating an invalid bitstream. '''The VTM encoder should not generate invalid bistreams without issuing a warning or error.'''" ksuehring 1589 "Different rate-distortion results when the value of ""REUSE_CU_RESULTS"" changes." VTM VTM-19.0 defect new 2023-01-22T17:12:05+01:00 2023-01-22T17:20:51+01:00 "In the current master of VTM, commit 796c74ad, the rate-distortion results when “REUSE_CU_RESULTS” is equal to 1 and those when “REUSE_CU_RESULTS” is equal to 0 are not identical. Given that “REUSE_CU_RESULTS at 1 enables to reuse the compression information of a past CU that is “equivalent” to the current CU to be compressed, the rate-distortion results for these two cases must be identical. Please find attached “bjontegaards_ai_one_vtm_19_hhi_master_2023_18_01_reuse_cu_results_off.csv” and “bjontegaards_ai_one_vtm_19_hhi_master_2023_18_01_reuse_cu_results_on.csv” the two rate-distortion results using commit 796c74ad when “REUSE_CU_RESULTS” is 0 and “REUSE_CU_RESULTS” is 1 respectively, in AI single frame. " dumas 1611 Segmentation fault occurred on VTM-21.0 with the two-layer-independent configuration on specific sequences under the lowdelay configuration. VTM VTM-21.0 defect new 2023-09-01T13:35:09+02:00 2023-09-07T14:25:34+02:00 "We ran VTM-21.0 in two-layer independent mode using the JVET VVC CTC sequences. The configuration and input of these two layers are identical. We found that VTM only crashed with SlideShow and SlideEditing sequences under the LDB configuration. All other sequences (including Class A, Class B, Class C, Class D, Class E, Class F), as well as this two sequences with the allintra or random-access configuration, can be encoded normally. The shell commands we used are as follows: EncoderApp -c cfg/encoder_lowdelay_vtm.cfg -c cfg/multi-layer/two_layers_independent.cfg -l0 -c cfg/per-class/classF.cfg -l0 -c cfg/per-sequence/SlideEditing.cfg -l0 -i SlideEditing_1280x720_30.yuv -l0 -q 37 -l1 -c cfg/per-class/classF.cfg -l1 -c cfg/per-sequence/SlideEditing.cfg -l1 -i SlideEditing_1280x720_30.yuv -l1 -q 37 --SEIDecodedPictureHash=1 --PrintHexPSNR=1 --Verbosity=6 -o '' -b SlideEditing.bin During our debugging process, we found that the crash occurred in the function EncGOP::xPicInitHashME (EncGOP.cpp line:1997). Specifically, when compressing the layer0 with POC equals to 9, the referenced flag of layer1 POC10 is true and this slice in rcListPic didn't initialized, thus triggering an error. This issue exists on both windows and linux os with VTM21.0 and VTM21.2. We also found that other sequences which run well in release version on window os but crash with array index out of bound error with debug mode using visual studio 2019 x64 under multi-layer configuration. " zixiang 1612 PO-SEI cannot process correctly using the default configuration file. VTM VTM-21.0 defect new 2023-09-01T15:13:14+02:00 2023-09-26T01:00:48+02:00 "The default cfg/sei_vui/sei_precessing_order.cfg is not correctly processed by VTM-21.0. EncAppCfg.cpp line 732 defined cfg_poSEIPrefixFlag as multi-value input with the number of the values is 0 or 1, but the CHECK() function at line 3604 demands that there should be at least 2 SEIPOPrefixFlag. This inconsistency results in VTM not being able to start properly using the default configuration po-sei file." zixiang 1614 Select maximun and minimun TU size VTM VTM-21.0 task new 2023-09-15T15:54:16+02:00 2023-09-15T22:27:43+02:00 I get an error message (Unknown option) when I try to use the options QuadtreeTULog2MaxSize and QuadtreeTULog2MinSize. These options are available in the software manual in table 7. I would appreciate if someone can guide me on specifying the size of TU, ​​I want to study the impact of DCT-II on 64x64 blocks. RicardoVilla 1610 Frame lost when the default NNPF config files are applied in coding. VTM VTM-21.2 defect new 2023-09-01T12:02:13+02:00 2023-09-01T12:02:13+02:00 "VTM version is VTM-21.2, and the encoding configuration is random access (RA) with the given random access config file. Using the default NNPF config files to compress video, frames could be lost in the decoded YUV file in the decoding process, while no frame lost in the reconstructed YUV file in encoding process. Here are the sequence names and the related settings when frames are lost. (QP is 63 to save coding time.) ||= sequence name =||= FrameSkip =||= FrameToBeEncoded =||= BitDepth =|| || BQMall_832x480_60 || 471 || 129 || 8|| || BQSquare_416x240_60 || 471 || 129 || 8|| || BasketballDrill_832x480_50 || 0 || 500 || 8|| || PartyScene_832x480_50 || 0 || 500 || 8|| || BasketballPass_416x240_50 || 0 || 500 || 8|| || BlowingBubbles_416x240_50 || 0 || 500 || 8|| || TVD-01_1 || 1500 || 500 || 8|| || TVD-01_2 || 2000 || 500 || 8|| || TVD-01_3 || 2500 || 500 || 8|| || TVD-02_1 || 0 || 636 || 10|| || TVD-03_1 || 0 || 500 || 10|| || TVD-03_2 || 500 || 500 || 10|| || TVD-03_3 || 1000 || 500 || 10|| Note: The TVD* sequences can be downloaded from https://multimedia.tencent.com/resources/tvd, clicking ""Download Video Sequences with Annotations for Object Tracking"" button and following the illustrations in https://jvet-experts.org/doc_end_user/documents/31_Geneva/wg11/JVET-AE2031-v1.zip to convert the .mp4 files into YUV files. " shurunwang 1626 xParseSEIBufferingPeriod does not match spec, code omits some syntax elements VTM VTM-23.0 defect new 2024-01-25T09:28:05+01:00 2024-01-26T15:00:43+01:00 "The code in source/Lib/DecoderLib/SEIRead.cpp reads: {{{ void SEIReader::xParseSEIBufferingPeriod ... for (i = (sei.m_sublayerInitialCpbRemovalDelayPresentFlag ? 0 : sei.m_bpMaxSubLayers - 1); i < sei.m_bpMaxSubLayers; i++) { for( nalOrVcl = 0; nalOrVcl < 2; nalOrVcl ++ ) { if( ( ( nalOrVcl == 0 ) && ( sei.m_bpNalCpbParamsPresentFlag ) ) || ( ( nalOrVcl == 1 ) && ( sei.m_bpVclCpbParamsPresentFlag ) ) ) { for( int j = 0; j < ( sei.m_bpCpbCnt ); j ++ ) { sei_read_code( pDecodedMessageOutputStream, sei.m_initialCpbRemovalDelayLength, code, nalOrVcl ? ""vcl_initial_cpb_removal_delay[i][j]"" : ""nal_initial_cpb_removal_delay[i][j]"" ); sei.m_initialCpbRemovalDelay[i][j][nalOrVcl] = code; sei_read_code( pDecodedMessageOutputStream, sei.m_initialCpbRemovalDelayLength, code, nalOrVcl ? ""vcl_initial_cpb_removal_offset[i][j]"" : ""nal_initial_cpb_removal_offset[i][j]"" ); sei.m_initialCpbRemovalOffset[i][j][nalOrVcl] = code; } } } } }}} This corresponds to D.3.1 of the specification: {{{ for( i = ( bp_sublayer_initial_cpb_removal_delay_present_flag ? 0 : bp_max_sublayers_minus1 ); i <= bp_max_sublayers_minus1; i++ ) { if( bp_nal_hrd_params_present_flag ) for( j = 0; j < bp_cpb_cnt_minus1 + 1; j++ ) { bp_nal_initial_cpb_removal_delay[ i ][ j ] u(v) bp_nal_initial_cpb_removal_offset[ i ][ j ] u(v) if( bp_du_hrd_params_present_flag) { bp_nal_initial_alt_cpb_removal_delay[ i ][ j ] u(v) bp_nal_initial_alt_cpb_removal_offset[ i ][ j ] u(v) } } if( bp_vcl_hrd_params_present_flag ) for( j = 0; j < bp_cpb_cnt_minus1 + 1; j++ ) { bp_vcl_initial_cpb_removal_delay[ i ][ j ] u(v) bp_vcl_initial_cpb_removal_offset[ i ][ j ] u(v) if( bp_du_hrd_params_present_flag ) { bp_vcl_initial_alt_cpb_removal_delay[ i ][ j ] u(v) bp_vcl_initial_alt_cpb_removal_offset[ i ][ j ] u(v) } } } }}} The issue is that the VTM is missing code to parse the syntax elements bp_nal_initial_alt_cpb_removal_delay, bp_nal_initial_alt_cpb_removal_offset, bp_vcl_initial_alt_cpb_removal_delay, bp_vcl_initial_alt_cpb_removal_offset. The encoder is also missing code to write these syntax elements. (This bug is present in the latest VTM-23.0, but there does not seem to be an option in the Version dropdown for VTM-23.0.)" peterderivaz 1633 Encoder crashes when combining 16bit-cfg-file with multilayer-cfg-file VTM VTM-23.0 defect new 2024-01-25T13:05:57+01:00 2024-01-25T13:05:57+01:00 "The Encoder works with lowdelay-P-16bit-cfg-file single-layer and also with lowdelay-P-10bit-cfg-file for two-layers using the two-layers-cfg-file. When trying to combine lowdelay-P-16bit-cfg with two-layer encoding the Encoder throws the following error: {{{ In function ""xInitLibCfg"" in /[...]/VVCSoftware_VTM23.0/source/App/EncoderApp/EncApp.cpp:226: ptl_multilayer_enabled_flag shall be equal to 0 for non-multilayer profiles }}} The profile is set to auto in the lowdelay-P-16bit-cfg-file and this configuration works for single-layer encoding. The shell command for the encoder is the following: {{{ EncoderAppStatic --MultiLayerEnabledFlag=1 -c encoder_lowdelay_P_16bit.cfg -c two-layers.cfg -b [...].266 -o [...].yuv -l0 --InputFile=""[...]"" -l0 --InputBitDepth=16 -l0 --InputChromaFormat=420 -l0 --FrameRate=100 -l0 --FramesToBeEncoded=50 -l0 --SourceWidth=128 -l0 --SourceHeight=128 -l0 -q 2 -l1 --InputFile=""[...]"" -l1 --InputBitDepth=16 -l1 --InputChromaFormat=420 -l1 --FrameRate=100 -l1 --FramesToBeEncoded=50 -l1 --FrameSkip=0 -l1 --SourceWidth=128 -l1 --SourceHeight=128 -l1 -q 2 --Level=5.2 }}} The encoder_lowdelay_P_16bit.cfg is the merge of all cfg-files used for configuration for CTC for high bit depth and high bit rate video coding (JVET-AA2018-v2)." pmeinicke 1636 multilayer coding fails when coding layers with different number of frames VTM VTM-23.0 defect new 2024-01-29T16:25:09+01:00 2024-01-29T16:25:09+01:00 "Coding with profile multilayer_main_10 and 2 layers. When using the same number of frames for every layer the coder works. For example, using an input file with 100 frames and setting --FramesToBeEncoded for every layer to 50. When setting --FramesToBeEncoded to different values for every layer, for example, using an input file with 100 frames and setting the value of --FramesToBeEncoded to 40 and 60, the encoder breaks before printing the summary to the log-file and puts out following error: {{{ terminate called after throwing an instance of 'Exception' what(): ERROR: In function ""printOutSummary"" in /[...]/VVCSoftware_VTM23.0/source/Lib/EncoderLib/EncGOP.cpp:4616: Unspecified error }}} Used following call for the encoder: {{{ EncoderAppStatic --MultiLayerEnabledFlag=1 -c encoder_lowdelay_multilayer.cfg -c two_layers_independent.cfg -b [...].266 -o [...].yuv -l0 --InputFile=""[...]"" -l0 --InputBitDepth=10 -l0 --InputChromaFormat=420 -l0 --FrameRate=100 -l0 --FramesToBeEncoded=40 -l0 --SourceWidth=128 -l0 --SourceHeight=128 -l0 -q 2 -l1 --InputFile=""[...]"" -l1 --InputBitDepth=10 -l1 --InputChromaFormat=420 -l1 --FrameRate=100 -l1 --FramesToBeEncoded=60 -l1 --FrameSkip=40 -l1 --SourceWidth=128 -l1 --SourceHeight=128 -l1 -q 2 --Level=5.2 }}} ""encoder_lowdelay_multilayer.cfg"" is a custom cfg-file for simple GOP structure with only first frame as Intra-coded and rest of the sequence as Inter-coded P-slices. ""two_layers_independent.cfg"" is the VTM standard cfg-file." pmeinicke 126 bug for calculating target bits in rate control in case of TemporalSubsampleRatio not equals to one VTM VTM-3.0 defect new 2018-12-02T14:46:31+01:00 2018-12-04T16:24:09+01:00 "In case of rate control is enabled, the sequence target bits is calculated from the given target rate.During the conversion from target rate to target bits, the frame rate should be considered. In VTM, the frame rate is constrained to be an integer number. So in case of temporal subsample ratio, the frame rate is divided and then rounded from the original value: {{{ (int)((double)m_iFrameRate / m_temporalSubsampleRatio + 0.5) }}} Right now, the target rate is set as the actually coded rate when the sequence is coded in QP 22, 27,32,37 with rate control disabled. When using the actually coded bits to calculate the actual rate, the frame rate is regarded as float number not int. In case of this inconsistency, the target bits set for rate control will be largely different from the actually coded bits. " liye0713 139 patch complementary for #126: about frame rate format in case of rate control VTM VTM-3.0 defect new 2018-12-24T10:32:27+01:00 2018-12-24T10:32:27+01:00 "In case of rate control is enabled, the sequence target bits is calculated from the given target rate.During the conversion from target rate to target bits, the frame rate should be considered. In VTM, the frame rate is constrained to be an integer number. So in case of temporal subsample ratio, the frame rate is divided and then rounded from the original value: (int)((double)m_iFrameRate / m_temporalSubsampleRatio + 0.5) Right now, the target rate is set as the actually coded rate when the sequence is coded in QP 22, 27,32,37 with rate control disabled. When using the actually coded bits to calculate the actual rate, the frame rate is regarded as float number not int. In case of this inconsistency, the target bits set for rate control will be largely different from the actually coded bits." liye0713 143 runtime error when INTRA_FULL_SEARCH set to 1 VTM VTM-3.0 defect new 2018-12-28T15:39:29+01:00 2019-07-23T19:11:19+02:00 "Intra full search is not supported when JVET_L0283_MULTI_REF_LINE is set to true. In estIntraPredLumaQT() (IntraSearch.cpp), if numModesForFullRD == numModesAvailable, uiRdModeList is filled with all modes while extendRefList remains empty. Runtime error occurs when accessing ""extendRefList"" in IntraSearch.cpp (line 694). " david.gommelet 226 Windows debug & release coding results not the same when IBC is ON for VTM4.0 VTM VTM-4.0 defect new 2019-03-14T02:37:21+01:00 2019-03-14T14:42:14+01:00 "The B frame coding results from Windows debug and release built version are not identical when IBC is turned on. When IBC is off, the coding results are the same. Attached is the debug/release coding log with IBC. " zhaoyin 206 Support .y4m input VTM VTM-4.0 enhancement new 2019-02-26T19:07:16+01:00 2022-02-24T13:47:51+01:00 "Allow [https://wiki.multimedia.cx/index.php/YUV4MPEG2 YUV4MPEG2] (.y4m) as input for the encoder. Some example implementations of other encoders: - SVT-AV1: https://github.com/OpenVisualCloud/SVT-AV1/blob/master/Source/App/EbAppInputy4m.c - AOM: https://github.com/mozilla/aom/blob/master/y4minput.c" EwoutH 209 Exception thrown in 'estIntraPredChromaQT' function VTM VTM-4.0.1 defect reopened 2019-02-28T09:51:09+01:00 2019-07-23T19:09:26+02:00 "The following encoding test is failing : git checkout 312ae1ef406ca37a545dafcb6019487acfa112dc cd build cmake .. make -j 8 cd .. bin/EncoderAppStatic --SourceWidth=120 --SourceHeight=88 --InputChromaFormat=420 --InputBitDepth=10 --Profile=next --FrameRate=60 --FramesToBeEncoded=2 --GOPSize=4 '--Frame1=B 1 5 -6.5 0.2590 0 0 1.0 0 0 0 4 4 -1 -5 -9 -13 0' '--Frame2=B 2 4 -6.5 0.2590 0 0 1.0 0 0 0 4 4 -1 -2 -6 -10 1 -1 5 1 1 1 0 1' '--Frame3=B 3 5 -6.5 0.2590 0 0 1.0 0 0 0 4 4 -1 -3 -7 -11 1 -1 5 0 1 1 1 1' '--Frame4=B 4 1 0.0 0.0 0 0 1.0 0 0 0 4 4 -1 -4 -8 -12 1 -1 5 0 1 1 1 1' --FastSearch=2 --MaxCUWidth=24 --MaxCUHeight=12 --MaxPartitionDepth=5 --TULog2MaxSize=6 --PCMEnabledFlag=1 --DisableIntraInInter=0 -i ./source.yuv -b ./encoded.vvc >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> terminate called after throwing an instance of 'Exception' what(): ERROR: In function ""estIntraPredChromaQT"" in ./source/Lib/EncoderLib/IntraSearch.cpp:1070: bestCostSoFar must be positive! /source/Lib/EncoderLib/IntraSearch.cpp:1070: bestCostSoFar must be positive! " fbarbier 294 ALF disabling at slice and tile boundaries not working VTM VTM-5.0 defect new 2019-05-29T14:09:28+02:00 2019-05-29T14:09:28+02:00 "ALF is performed across tile or slice boundaries even when loop filtering across tile or slice boundaries is disabled. to reproduce: {{{ # ALF on, two slice columns, no LF across slice boundaries bin/EncoderAppStatic -c cfg/encoder_randomaccess_vtm.cfg --OutputBitDepth=10 --OutputBitDepthC=10 --FramesToBeEncoded=10 --IntraPeriod=32 --Level=5.2 --QP=37 --FrameRate=30 --SourceHeight=768 --SourceWidth=512 --InputFile=Landing2_512x768_30Hz_10b_420.yuv --BitstreamFile=Landing2_512x768_QP37_noLFCrossSlices.vvc --ReconFile=Landing2_512x768_QP37_rec_enc_noLFCrossSlices.yuv --InputBitDepth=10 --InputChromaFormat=420 --SEIDecodedPictureHash=1 --TileUniformSpacing=1 --NumTileColumnsMinus1=1 --NumTileRowsMinus1=0 --SliceMode=3 --SliceArgument=1 --LFCrossSliceBoundaryFlag=0 --LFCrossTileBoundaryFlag=1 --LoopFilterDisable=1 --SAO=0 --ALF=1 # ALF on, two slice columns, LF across slice boundaries on bin/EncoderAppStatic -c cfg/encoder_randomaccess_vtm.cfg --OutputBitDepth=10 --OutputBitDepthC=10 --FramesToBeEncoded=10 --IntraPeriod=32 --Level=5.2 --QP=37 --FrameRate=30 --SourceHeight=768 --SourceWidth=512 --InputFile=Landing2_512x768_30Hz_10b_420.yuv --BitstreamFile=Landing2_512x768_QP37_withLFCrossSlices.vvc --ReconFile=Landing2_512x768_QP37_rec_enc_withLFCrossSlices.yuv --InputBitDepth=10 --InputChromaFormat=420 --SEIDecodedPictureHash=1 --TileUniformSpacing=1 --NumTileColumnsMinus1=1 --NumTileRowsMinus1=0 --SliceMode=3 --SliceArgument=1 --LFCrossSliceBoundaryFlag=1 --LFCrossTileBoundaryFlag=1 --LoopFilterDisable=1 --SAO=0 --ALF=1 # all LF on, two slice columns, no LF across slice boundaries bin/EncoderAppStatic -c cfg/encoder_randomaccess_vtm.cfg --OutputBitDepth=10 --OutputBitDepthC=10 --FramesToBeEncoded=10 --IntraPeriod=32 --Level=5.2 --QP=37 --FrameRate=30 --SourceHeight=768 --SourceWidth=512 --InputFile=Landing2_512x768_30Hz_10b_420.yuv --BitstreamFile=Landing2_512x768_QP37_noLFCrossSlicesAllLF.vvc --ReconFile=Landing2_512x768_QP37_rec_enc_noLFCrossSlicesAllLF.yuv --InputBitDepth=10 --InputChromaFormat=420 --SEIDecodedPictureHash=1 --TileUniformSpacing=1 --NumTileColumnsMinus1=1 --NumTileRowsMinus1=0 --SliceMode=3 --SliceArgument=1 --LFCrossSliceBoundaryFlag=0 --LFCrossTileBoundaryFlag=1 # all on, two slice columns, LF across slice boundaries on bin/EncoderAppStatic -c cfg/encoder_randomaccess_vtm.cfg --OutputBitDepth=10 --OutputBitDepthC=10 --FramesToBeEncoded=10 --IntraPeriod=32 --Level=5.2 --QP=37 --FrameRate=30 --SourceHeight=768 --SourceWidth=512 --InputFile=Landing2_512x768_30Hz_10b_420.yuv --BitstreamFile=Landing2_512x768_QP37_withLFCrossSlicesAllLF.vvc --ReconFile=Landing2_512x768_QP37_rec_enc_withLFCrossSlicesAllLF.yuv --InputBitDepth=10 --InputChromaFormat=420 --SEIDecodedPictureHash=1 --TileUniformSpacing=1 --NumTileColumnsMinus1=1 --NumTileRowsMinus1=0 --SliceMode=3 --SliceArgument=1 --LFCrossSliceBoundaryFlag=1 --LFCrossTileBoundaryFlag=1 }}} I used the master branch (commit 988c22cbb9c58584cac3ef0ec7794cafbea6dfd6), but disabled JVET_N0857_TILES_BRICKS since I did not figure out yet how to configure slices when it is on. When ALF is the only enabled loop filter, the output is the same (first two calls), but should be different. When all LFs are enabled (second two calls) the difference can be clearly seen at the slice boundary I attached the tiny test sequence I used. The configuration above splits the sequence in two columns, each of which is in a separate slice. I also could not find the description of disabling ALF at slice or tile boundaries in the VVC Draft." jsauer 339 Mismatch between SIMD_ENABLE macro ON and OFF VTM VTM-5.0 defect new 2019-06-25T04:14:18+02:00 2019-07-23T19:08:59+02:00 "In VTM-5.0, bitstream mismatch occurs in Tango (starting from POC32) when changing SIMD_ENABLE macro setting from 1 to 0. encoder log entry for bistream with SIMD_ENABLE set to 1 is: POC 32 TId: 0 ( B-SLICE, QP 33 ) 355320 bits [Y 39.6028 dB U 47.5340 dB V 45.2309 dB] [xY 4043cd29e05bd0a0 xU 4047c459ad47f722 xV 40469d8c8e04cd16] [ET 4344 ] [L0 16 0 ] [L1 16 0 ] encoder log entry for bitstream with SIMD_ENABLE set to 0 is: POC 32 TId: 0 ( B-SLICE, QP 33 ) 355416 bits [Y 39.6031 dB U 47.5429 dB V 45.2100 dB] [xY 4043cd327d712575 xU 4047c57c341bb96b xV 40469ae2a77e05e0] [ET 9592 ] [L0 16 0 ] [L1 16 0 ] Bitstream with SIMD_ENABLE off can be decoded by decoder with SIMD_ENABLE on without any problem, and vice versa. Test condition: RA CTC" Krit 215 Encoder fails when WP is enabled (WeightedPredP/WeightedPredB=1) VTM VTM-5.0rc1 defect new 2019-03-04T04:06:26+01:00 2019-05-20T17:06:39+02:00 "1. An exception is thrown from ""WeightPrediction.cpp:84"" in encoder when WeightedPredP and WeightedPredB is set to 1. 2. If AffineAmvr/AffineAmvrEncOpt is set to 0, no exception anymore but mismatch between encoder and decoder is observed. 3. If DMVR is set to 0 as well, mo mismatch. Both VTM_4.0 and VTM_4.0.1 have this problem." jiechen 677 Memory bandwidth calculation in DMVR and BDOF VTM VTM-6.0 defect new 2019-11-11T10:30:52+01:00 2020-07-12T17:41:48+02:00 "On measuring memory bandwidth of DMVR and/or BDOF, VTM outputs wrong memory bandwidth. In absence of DMVR, BDOF bandwidth numbers also looks incorrect. This defect has no impact to coding performance." sagarkotecha 518 VTM-6.0 tracing crashes with recent gcc VTM VTM-6.0 enhancement new 2019-09-11T03:23:35+02:00 2021-04-20T01:06:40+02:00 "When running the VTM-6.0 encoder with tracing compiled using gcc-9.1.0 and activated, the following error occurred: terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid Aborted (core dumped) However, using gcc-4.8.5 tracing is working OK." crosewarne 572 Incorrect use of chroma distortion weights if Cb and Cr QP offsets differ (affects perceptual QPA, may affect SBT in HDR-PQ CTCs) VTM VTM-6.1 defect new 2019-10-10T19:58:20+02:00 2020-07-12T17:41:48+02:00 "VTM 6.x, in ''initEncSlice()'', calls ''setUpLambda()'' to initialize the Cb and Cr distortion weights. These weights are computed, and multiplied onto the respective component distortions in ''RdCost::getDistPart()'', independently for Cb and Cr. However, there are some places where an '''average chroma weight''' is calculated via ''RdCost::getChromaWeight()'' and used for both Cb and Cr. This does not seem to be an issue with the SDR or HDR-HLG CTCs, but if I understand correctly, different Cb and Cr QP offsets (and, thus, different Cb and Cr lambdas) may occur in the HDR-PQ CTCs. Therefore, in the case of unequal Cb and Cr QP offsets, the following encoder functions may, according to my understanding, work suboptimally: * rate control (if pCfg->getUseRateCtrl() in ''encodeCtus()'', not sure if this is used) * perceptual QPA with chroma QP adaptation (e.g., if pCfg->getUsePerceptQPA() && pcSlice->getPPS()->getUseDQP() in ''encodeCtus()'') * SBT fast algorithm (''InterSearch::calcMinDistSbt()'' called in ''xEncodeInterResidual()''). Before I submit a merge request with a proposed fix (used of a RdCost::getDistortionWeight('''compID''') instead of the RdCost::getChromaWeight() at the respective places), it would be great if someone could confirm that my understanding is correct. Thanks and best, Christian " crhelmrich 468 ERROR: AddressSanitizer: unknown-crash VTM VTM-6.1 defect new 2019-08-19T17:22:14+02:00 2019-09-12T19:50:22+02:00 "When building with ASAN the VTM 6.0, a crash may be found using the following command lines : {{{ git checkout cb45f4386cf08d5b209333be61965a4beb4ff305 cd build readonly sanitizer=""-fsanitize=address"" cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=$sanitizer -DCMAKE_EXE_LINKER_FLAGS=$sanitizer make -j 8 cd .. ./bin/EncoderAppStaticd --SourceWidth=192 --SourceHeight=128 --InputChromaFormat=420 --InputBitDepth=8 --Profile=next --FrameRate=60 --FramesToBeEncoded=1 --GOPSize=4 --Frame1=""B 1 5 -6.5 0.2590 0 0 1.0 0 0 0 4 4 1 5 9 13 0 0"" --Frame2=""B 2 4 -6.5 0.2590 0 0 1.0 0 0 0 4 4 1 2 6 10 0 0"" --Frame3=""B 3 5 -6.5 0.2590 0 0 1.0 0 0 0 4 4 1 3 7 11 0 0"" --Frame4=""B 4 1 0.0 0.0 0 0 1.0 0 0 0 4 4 1 4 8 12 0 0"" --FastSearch=2 --LCTUFast=1 --PBIntraFast=1 --CTUSize=64 --MaxPartitionDepth=5 --PCMEnabledFlag=1 --SAO=1 --ALF=1 --DepQuant=1 --DualITree=1 --MaxDeltaQP=2 --MTS=3 --IMV=1 --Affine=1 --AffineType=1 --Triangle=1 --SBT=1 -i source.yuv -b encoded.vvc }}} Output is : {{{ VVCSoftware: VTM Encoder Version 6.0 [Linux][GCC 8.2.0][64 bit] [SIMD=AVX] TOOL CFG: IBD:0 HAD:1 RDQ:1 RDQTS:1 RDpenalty:0 LQP:0 SQP:0 ASR:0 MinSearchWindow:8 RestrictMESampling:0 FEN:0 ECU:0 FDM:1 CFM:0 ESD:0 TransformSkip:0 TransformSkipFast:0 TransformSkipLog2MaxSize:5 BDPCM:0 Slice: M=0 Tiles:1x1 MCTS:0 CIP:0 SAO:1 ALF:1 PCM:1 TransQuantBypassEnabled:0 WPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 DQ:1 SignBitHidingFlag:0 RecalQP:0 NEXT TOOL CFG: LFNST:0 MMVD:1 Affine:1 AffineType:1 PROF:0 SubPuMvp:0+0 DualITree:1 IMV:1 BIO:0 LMChroma:1 CclmCollocatedChroma:0 MTS: 1(intra) 1(inter) SBT:1 ISP:0 SMVD:0 CompositeLTReference:0 GBi:0 GBiFast:0 LADF:0 MHIntra:0 Triangle:1 AllowDisFracMMVD:0 AffineAmvr:0 AffineAmvrEncOpt:0 DMVR:0 MmvdDisNum:8 JointCbCr:0 PLT:0 IBC:0 HashME:0 WrapAround:0 LoopFilterAcrossVirtualBoundaries:0 Reshape:0 MIP:1 EncDbOpt:0 FAST TOOL CFG: LCTUFast:1 FastMrg:0 PBIntraFast:1 IMV4PelFast:1 MTSMaxCand: 3(intra) 4(inter) AMaxBT:0 E0023FastEnc:1 ContentBasedFastQtbt:0 UseNonLinearAlfLuma:1 UseNonLinearAlfChroma:1 MaxNumAlfAlternativesChroma:8 FastMIP:0 FastLocalDualTree:0 NumSplitThreads:1 NumWppThreads:1+0 EnsureWppBitEqual:0 started @ Mon Aug 19 17:12:37 2019 ================================================================= ==28801==ERROR: AddressSanitizer: unknown-crash on address 0x62f00002933c at pc 0x55c7f6d1982a bp 0x7ffdbd761fc0 sp 0x7ffdbd761fb8 READ of size 16 at 0x62f00002933c thread T0 #0 0x55c7f6d19829 in _mm_loadu_si128(long long __vector(2) const*) /usr/lib/gcc/x86_64-linux-gnu/8/include/emmintrin.h:703 #1 0x55c7f6d19829 in simdDeriveClassificationBlk<(X86_VEXT)3> /home/fredb/projects/vtm/source/Lib/CommonLib/x86/avx/../AdaptiveLoopFilterX86.h:100 #2 0x55c7f721ced4 in AdaptiveLoopFilter::deriveClassification(AlfClassifier**, AreaBuf const&, Area const&, Area const&) /home/fredb/projects/vtm/source/Lib/CommonLib/AdaptiveLoopFilter.cpp:750 #3 0x55c7f70bc929 in EncAdaptiveLoopFilter::ALFProcess(CodingStructure&, double const*, double) /home/fredb/projects/vtm/source/Lib/EncoderLib/EncAdaptiveLoopFilter.cpp:770 #4 0x55c7f6e86a95 in EncGOP::compressGOP(int, int, std::__cxx11::list >&, std::__cxx11::list*, std::allocator*> >&, bool, bool, InputColourSpaceConversion, bool, bool) /home/fredb/projects/vtm/source/Lib/EncoderLib/EncGOP.cpp:2518 #5 0x55c7f6ec2140 in EncLib::encode(bool, PelStorage*, PelStorage*, InputColourSpaceConversion, std::__cxx11::list*, std::allocator*> >&, int&) /home/fredb/projects/vtm/source/Lib/EncoderLib/EncLib.cpp:637 #6 0x55c7f6a17233 in EncApp::encode() /home/fredb/projects/vtm/source/App/EncoderApp/EncApp.cpp:779 #7 0x55c7f6ad29f9 in main /home/fredb/projects/vtm/source/App/EncoderApp/encmain.cpp:153 #8 0x7ffa43a1a09a in __libc_start_main ../csu/libc-start.c:308 #9 0x55c7f6a0adb9 in _start (/home/fredb/projects/vtm/bin/EncoderAppStaticd+0x339db9) 0x62f000029348 is located 0 bytes to the right of 53064-byte region [0x62f00001c400,0x62f000029348) allocated by thread T0 here: #0 0x7ffa44016038 in __interceptor_posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xea038) #1 0x55c7f6aec604 in short* detail::aligned_malloc(unsigned long, unsigned long) /home/fredb/projects/vtm/source/Lib/CommonLib/CommonDef.h:604 #2 0x55c7f6ae35ed in PelStorage::create(ChromaFormat const&, Area const&, unsigned int, unsigned int, unsigned int, bool) /home/fredb/projects/vtm/source/Lib/CommonLib/Buffer.cpp:799 #3 0x55c7f721b5cd in AdaptiveLoopFilter::create(int, int, ChromaFormat, int, int, int, int const*) /home/fredb/projects/vtm/source/Lib/CommonLib/AdaptiveLoopFilter.cpp:652 #4 0x55c7f70b71f9 in EncAdaptiveLoopFilter::create(EncCfg const*, int, int, ChromaFormat, int, int, int, int const*, int const*) /home/fredb/projects/vtm/source/Lib/EncoderLib/EncAdaptiveLoopFilter.cpp:423 #5 0x55c7f6ebe72f in EncLib::create() /home/fredb/projects/vtm/source/Lib/EncoderLib/EncLib.cpp:148 #6 0x55c7f6a16276 in EncApp::xCreateLib(std::__cxx11::list*, std::allocator*> >&) /home/fredb/projects/vtm/source/App/EncoderApp/EncApp.cpp:666 #7 0x55c7f6a1698f in EncApp::encode() /home/fredb/projects/vtm/source/App/EncoderApp/EncApp.cpp:713 #8 0x55c7f6ad29f9 in main /home/fredb/projects/vtm/source/App/EncoderApp/encmain.cpp:153 #9 0x7ffa43a1a09a in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: unknown-crash /usr/lib/gcc/x86_64-linux-gnu/8/include/emmintrin.h:703 in _mm_loadu_si128(long long __vector(2) const*) Shadow bytes around the buggy address: 0x0c5e7fffd210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5e7fffd220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5e7fffd230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5e7fffd240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5e7fffd250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c5e7fffd260: 00 00 00 00 00 00 00[00]00 fa fa fa fa fa fa fa 0x0c5e7fffd270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e7fffd280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e7fffd290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e7fffd2a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5e7fffd2b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==28801==ABORTING }}}" fbarbier 507 Signalling of RPL in slice header of IDR picture VTM VTM-6.1 defect new 2019-09-07T04:16:00+02:00 2020-07-12T17:41:48+02:00 "When sps_idr_rpl_present_flag is equal to 1, RPL signaling is present SH of IDR pictures. This RPL signaling can be local RPL or by referencing to the candidate RPL structures in SPS. Current implementation does not allow RPL signaling by referencing to available candidates RPL structures in SPS. The following MR provides fix for the issue. https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/919" hendry197 521 Platform-inconsistent results for palette, RA, qp=2 VTM VTM-6.1 defect new 2019-09-12T10:47:28+02:00 2019-09-12T10:55:01+02:00 " With qp=2 RA encodes, the calculated qp for intra frames arrives as -1. In IntraSearch::preCalcPLTIndex and IntraSearch::derivePLTLossy this value is used as an index into a table, which is out of bounds, causing different results on different platforms. The attached patch resolves the problem, but might be considered a 'band aid' -- there is still the issue of a negative qp value arriving in the code, causing, possibly, other potential issues either now or later. Should a merge request be made for this patch, or should we wait for a higher level fix? " gordon 539 Add fix in EncGOP.cpp to new HDRTools v0.20+ VTM VTM-6.1 defect new 2019-09-21T08:38:06+02:00 2019-09-25T19:16:20+02:00 "Add fix in EncGOP.cpp to new HDRTools v0.19+ if (m_pcEncLib->getPrintHexPsnr()) { m_pcDistortionDeltaE = new hdrtoolslib::DistortionMetricDeltaE(m_pcFrameFormat, false, maxSampleValue, whitePointDeltaE, 1, true); } else { m_pcDistortionDeltaE = new hdrtoolslib::DistortionMetricDeltaE(m_pcFrameFormat, false, maxSampleValue, whitePointDeltaE, 1, false); } https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/855#note_7158" Jamaika 540 Problem with 360lib VTM VTM-6.1 defect new 2019-09-21T08:50:46+02:00 2019-10-03T11:51:19+02:00 "Tutorial: Generate Microsoft Visual Studio Solution for VTM+360Lib— 360-Degree Video Using VVC Codec (Video Coding) https://medium.com/@sh.tsang/tutorial-generate-microsoft-visual-studio-solution-for-vtm-360lib-360-degree-video-using-vvc-7ee40aa957f4 When I add the 260lib library the codec doesn't work. https://jvet.hhi.fraunhofer.de/svn/svn_360Lib/tags/360Lib-9.1/" Jamaika 542 The proposal displaying information on the input video. VTM VTM-6.1 defect new 2019-09-23T16:14:59+02:00 2020-07-12T17:41:48+02:00 "The proposal displaying information on the input video. '''Change EncAppCfg.cpp:''' {{{ (""FrameRate,-fr"", m_iFrameRate, 0.0, ""Frame rate"") }}} {{{ m_switchPocPeriod = (int) m_iFrameRate / 2 / m_iGOPSize * m_iGOPSize; }}} {{{ m_reshapeCW.rspFps = (int) m_iFrameRate; }}} {{{ msg( VERBOSE, ""Input real format : %dx%d %.3fHz\n"", m_iSourceWidth - m_confWinLeft - m_confWinRight, m_iSourceHeight - m_confWinTop - m_confWinBottom, (double)m_iFrameRate / m_temporalSubsampleRatio ); }}} {{{ msg( VERBOSE, ""Input format pixel & bitdepth : ""); if (m_chromaFormatConstraint == CHROMA_444) { msg(VERBOSE, ""%s"", ( m_chromaFormatConstraint ? ""yuv444"" : """") ); } else if (m_chromaFormatConstraint == CHROMA_422) { msg(VERBOSE, ""%s"", ( m_chromaFormatConstraint ? ""yuv422"" : """") ); } else if (m_chromaFormatConstraint == CHROMA_420) { msg(VERBOSE, ""%s"", ( m_chromaFormatConstraint ? ""yuv420"" : """") ); } else { msg(VERBOSE, ""%s"", ( m_chromaFormatConstraint ? ""yuv400"" : """") ); } if (m_interlacedSourceFlag == 1) { msg( VERBOSE, ""i"" ); } else { msg( VERBOSE, ""p"" ); } msg( VERBOSE, ""%dle\n"", m_inputBitDepth[CHANNEL_TYPE_LUMA] ); if (m_lumaReshapeEnable == 1) { msg( VERBOSE, ""Input signal type : ""); if (m_reshapeSignalType == RESHAPE_SIGNAL_SDR) { msg(VERBOSE, ""%s"", ( m_reshapeSignalType ? ""SDR"" : """") ); } else if (m_reshapeSignalType == RESHAPE_SIGNAL_PQ) { msg(VERBOSE, ""%s"", ( m_reshapeSignalType ? ""HDR-PQ"" : """") ); } else if (m_reshapeSignalType == RESHAPE_SIGNAL_HLG) { msg(VERBOSE, ""%s"", ( m_reshapeSignalType ? ""HDR-HLG"" : """") ); } else { msg(VERBOSE, ""%s"", ( m_reshapeSignalType ? ""Undef"" : """") ); } msg( VERBOSE, ""\n"" ); } msg( VERBOSE, ""Input color space / primaries : ""/*, m_transferCharacteristics*/); if (m_matrixCoefficients == 0) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""RGB24"" : """") ); } else if (m_matrixCoefficients == 1) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""BT709"" : """") ); } else if (m_matrixCoefficients == 2) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""Undef"" : """") ); } else if (m_matrixCoefficients == 3) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""Reserve"" : """") ); } else if (m_matrixCoefficients == 4) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""USFCCT47"" : """") ); } else if (m_matrixCoefficients == 5) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""BT601^625"" : """") ); } else if (m_matrixCoefficients == 6) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""BT601^525"" : """") ); } else if (m_matrixCoefficients == 7) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""SMPTE 340"" : """") ); } else if (m_matrixCoefficients == 8) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""YCgCo"" : """") ); } else if (m_matrixCoefficients == 9) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""BT2020nc "" : """") ); } else if (m_matrixCoefficients == 10) { msg(VERBOSE, ""%s"", ( m_matrixCoefficients ? ""BT2020c"" : """") ); } msg( VERBOSE, ""/""); if (m_colorPrimaries == -1) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""Undef"" : """") ); } else if (m_colorPrimaries == 0) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""BT709"" : """") ); } else if (m_colorPrimaries == 1) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""BT2020"" : """") ); } else if (m_colorPrimaries == 2) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""P3D60"" : """") ); } else if (m_colorPrimaries == 3) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""P3D65"" : """") ); } else if (m_colorPrimaries == 4) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""XYZ"" : """") ); } else if (m_colorPrimaries == 5) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""None"" : """") ); } else if (m_colorPrimaries == 6) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""AMD"" : """") ); } else if (m_colorPrimaries == 7) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""YCgCo"" : """") ); } else if (m_colorPrimaries == 8) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""EXT"" : """") ); } else if (m_colorPrimaries == 9) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""LMSD"" : """") ); } else if (m_colorPrimaries == 10) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""BT601"" : """") ); } else if (m_colorPrimaries == 11) { msg(VERBOSE, ""%s"", ( m_colorPrimaries ? ""P3D65N"" : """") ); } msg( VERBOSE, ""\n"" ); msg( VERBOSE, ""Input color range : %s\n"", (m_sampleRange ? ""full"" : ""limited"" ) ); }}} {{{ msg( VERBOSE, ""Frame/Field : Field based coding\n"" ); msg( VERBOSE, ""Field index : %u - %d (%d fields)\n"", m_FrameSkip, m_FrameSkip + m_framesToBeEncoded - 1, m_framesToBeEncoded ); msg( VERBOSE, ""Field Order : %s field first\n"", m_isTopFieldFirst ? ""top"" : ""bottom"" ); }}} {{{ msg( VERBOSE, ""Frame/Field : Frame based coding\n"" ); msg( VERBOSE, ""Frame index : %u - %d (%d frames)\n"", m_FrameSkip, m_FrameSkip + m_framesToBeEncoded - 1, m_framesToBeEncoded ); }}} {{{ msg( VERBOSE, ""Profile : %s (%s)\n"", profileToString(m_profile), (rextSubProfile.empty())?""INVALID REXT PROFILE"":rextSubProfile.c_str() ); }}} {{{ msg( VERBOSE, ""Profile : %s\n"", profileToString(m_profile) ); }}} '''Change EncAppCfg.h:''' {{{ double m_iFrameRate; ///< source frame-rates (Hz) }}} '''Change EncLib.cpp:''' {{{ m_cRateCtrl.initHrdParam(sps0.getHrdParameters(), (int) m_iFrameRate, m_RCInitialCpbFullness); }}} '''Change EncCfg.h:''' {{{ double m_iFrameRate; }}} {{{ void setFrameRate ( double i ) { m_iFrameRate = i; } }}} " Jamaika 544 Implicit partitonning issue when CtbSizeY = 128 and dual tree VTM VTM-6.1 defect new 2019-09-24T17:03:43+02:00 2019-09-24T17:03:43+02:00 "In the specification, when CtbSizeY = 128, qtbtt_dual_tree_intra_flag = 1 and slice_type = I, the Ctb is implicitly split in a 64x64 Cb, independently of the value of the different Cb, QT, BT and TT size constraints present in the SPS and in the slice header. Therefore, for example, the specification allows the combination qtbtt_dual_tree_intra_flag = 1 and MinCbSizeY = 128. In this case all Cb will be implicitely to 64x64 in the intra slices. However, the VTM still call the canSplit function when doing this, which tests the different size constraints. This could lead to value of splitMode different from CU_QUAD_SPLIT at the first depth." forayr 548 [Tile] Wrong Intra Mode for first PU of second Tile VTM VTM-6.1 defect new 2019-09-26T17:19:12+02:00 2019-09-26T17:19:12+02:00 "Use Case: 2 Uniform Tiles in AI configuration. First PU of first Tile, intramode = Planar (OK) First PU of second Tile, intramode = 22 (! KO !) Seen on Version 6.1, commit 240eedcfa676a504a7ad0c71f16f4045ff76d1cd." tamestoy 620 MSYS2/MinGW/GCC9: InterpolationFilter_avx.cpp: x86 compile trying to use x86-64 intrinsics VTM VTM-6.2 defect new 2019-10-25T08:41:59+02:00 2020-07-12T17:41:48+02:00 "CFLAGS: -mthreads -mtune=generic -O2 -pipe LDFLAGS: -pipe -static-libgcc -static-libstdc++ {{{ [6/141] Building CXX object source/Lib/CommonAnalyserLib/CMakeFiles/CommonAnalyserLib.dir/__/CommonLib/x86/avx/InterpolationFilter_avx.cpp.o FAILED: source/Lib/CommonAnalyserLib/CMakeFiles/CommonAnalyserLib.dir/__/CommonLib/x86/avx/InterpolationFilter_avx.cpp.o E:\MABS\local32\bin\g++.bat -DENABLE_SPLIT_PARALLELISM=0 -DRExt__DECODER_DEBUG_BIT_STATISTICS=1 -DRExt__DECODER_DEBUG_TOOL_STATISTICS=1 -DUSE_AVX -I../source/Lib/CommonAnalyserLib/../CommonLib/. -I../source/Lib/CommonAnalyserLib/../CommonLib/.. -I../source/Lib/CommonAnalyserLib/../CommonLib/x86 -I../source/Lib/CommonAnalyserLib/../libmd5 -mthreads -mtune=generic -O2 -pipe -fopenmp -O3 -DNDEBUG -Wall -fdiagnostics-show-option -Werror -Wno-sign-compare -Wno-class-memaccess -msse4.1 -mthreads -std=gnu++11 -mavx -MD -MT source/Lib/CommonAnalyserLib/CMakeFiles/CommonAnalyserLib.dir/__/CommonLib/x86/avx/InterpolationFilter_avx.cpp.o -MF source\Lib\CommonAnalyserLib\CMakeFiles\CommonAnalyserLib.dir\__\CommonLib\x86\avx\InterpolationFilter_avx.cpp.o.d -o source/Lib/CommonAnalyserLib/CMakeFiles/CommonAnalyserLib.dir/__/CommonLib/x86/avx/InterpolationFilter_avx.cpp.o -c ../source/Lib/CommonLib/x86/avx/InterpolationFilter_avx.cpp In file included from ../source/Lib/CommonLib/x86/avx/InterpolationFilter_avx.cpp:1: ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h: In function 'void simdInterpolateN2_HIGHBIT_M4(const int16_t*, int, int16_t*, int, int, int, int, int, int, const ClpRng&, const int16_t*)': ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1085:21: error: there are no arguments to '_mm_cvtsi64_si128' that depend on a template parameter, so a declaration of '_mm_cvtsi64_si128' must be available [-fpermissive] 1085 | __m128i mmShift = _mm_cvtsi64_si128(shift); | ^~~~~~~~~~~~~~~~~ ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1085:21: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h: In instantiation of 'void simdInterpolateN2_HIGHBIT_M4(const int16_t*, int, int16_t*, int, int, int, int, int, int, const ClpRng&, const int16_t*) [with X86_VEXT vext = AVX; bool isLast = false; int16_t = short int]': ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1284:53: required from 'void simdFilter(const ClpRng&, const Pel*, int, Pel*, int, int, int, const TFilterCoeff*, bool) [with X86_VEXT vext = AVX; int N = 8; bool isVertical = false; bool isFirst = false; bool isLast = false; Pel = short int; TFilterCoeff = short int]' ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1447:24: required from 'void InterpolationFilter::_initInterpolationFilterX86() [with X86_VEXT vext = AVX]' ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1485:73: required from here ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1085:38: error: '_mm_cvtsi64_si128' was not declared in this scope; did you mean '_mm_cvtsi32_si128'? 1085 | __m128i mmShift = _mm_cvtsi64_si128(shift); | ~~~~~~~~~~~~~~~~~^~~~~~~ | _mm_cvtsi32_si128 ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h: In instantiation of 'void simdInterpolateN2_HIGHBIT_M4(const int16_t*, int, int16_t*, int, int, int, int, int, int, const ClpRng&, const int16_t*) [with X86_VEXT vext = AVX; bool isLast = true; int16_t = short int]': ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1284:53: required from 'void simdFilter(const ClpRng&, const Pel*, int, Pel*, int, int, int, const TFilterCoeff*, bool) [with X86_VEXT vext = AVX; int N = 8; bool isVertical = false; bool isFirst = false; bool isLast = true; Pel = short int; TFilterCoeff = short int]' ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1448:24: required from 'void InterpolationFilter::_initInterpolationFilterX86() [with X86_VEXT vext = AVX]' ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1485:73: required from here ../source/Lib/CommonLib/x86/avx/../InterpolationFilterX86.h:1085:38: error: '_mm_cvtsi64_si128' was not declared in this scope; did you mean '_mm_cvtsi32_si128'? 1085 | __m128i mmShift = _mm_cvtsi64_si128(shift); | ~~~~~~~~~~~~~~~~~^~~~~~~ | _mm_cvtsi32_si128 }}} " ligh_de 622 Incorrect use of getComponentScaleX() for LM, DMVR, and QPA VTM VTM-6.2 defect new 2019-10-25T14:01:16+02:00 2019-10-25T14:01:16+02:00 "1. In {{{IntraPrediction::xGetLMParameters()}}} {{{ const int unitWidth = baseUnitSize >> getComponentScaleX(chromaArea.compID, nChromaFormat); const int unitHeight = baseUnitSize >> getComponentScaleX(chromaArea.compID, nChromaFormat); }}} should be corrected as following: {{{ const int unitWidth = baseUnitSize >> getComponentScaleX(chromaArea.compID, nChromaFormat); const int unitHeight = baseUnitSize >> getComponentScaleY(chromaArea.compID, nChromaFormat); }}} 2. In {{{InterPrediction::xPrefetch()}}} {{{ int mvshiftTemp = mvShift + getComponentScaleX((ComponentID)compID, pu.chromaFormat); width += (filtersize - 1); height += (filtersize - 1); cMv += Mv(-(((filtersize >> 1) - 1) << mvshiftTemp), -(((filtersize >> 1) - 1) << mvshiftTemp)); ... Position Rec_offset = pu.blocks[compID].pos().offset(cMv.getHor() >> mvshiftTemp, cMv.getVer() >> mvshiftTemp); }}} should be corrected as following: {{{ int mvshiftTempHor = mvShift + getComponentScaleX((ComponentID)compID, pu.chromaFormat); int mvshiftTempVer = mvShift + getComponentScaleY((ComponentID)compID, pu.chromaFormat); width += (filtersize - 1); height += (filtersize - 1); cMv += Mv(-(((filtersize >> 1) - 1) << mvshiftTempHor), -(((filtersize >> 1) - 1) << mvshiftTempVer)); ... Position Rec_offset = pu.blocks[compID].pos().offset(cMv.getHor() >> mvshiftTempHor, cMv.getVer() >> mvshiftTempVer); }}} 3. In {{{InterPrediction::xPad()}}} Different pad sizes should be used for width and height in 4:2:2 sequences. The simplest way to solve it is to use the larger one. {{{ padsize = (DMVR_NUM_ITERATION) >> getComponentScaleX((ComponentID)compID, pu.chromaFormat); }}} should be corrected as following: {{{ padsize = (DMVR_NUM_ITERATION) >> getComponentScaleY((ComponentID)compID, pu.chromaFormat); }}} 4. In {{{InterPrediction::xFinalPaddedMCForDMVR()}}} {{{ int mvshiftTemp = mvShift + getComponentScaleX((ComponentID)compID, pu.chromaFormat); int leftPixelExtra; if (compID == COMPONENT_Y) { leftPixelExtra = (NTAPS_LUMA >> 1) - 1; } else { leftPixelExtra = (NTAPS_CHROMA >> 1) - 1; } PelBuf &srcBuf = pcPadTemp.bufs[compID]; deltaIntMvX = (cMv.getHor() >> mvshiftTemp) - (startMv.getHor() >> mvshiftTemp); deltaIntMvY = (cMv.getVer() >> mvshiftTemp) - (startMv.getVer() >> mvshiftTemp); }}} should be corrected as following: {{{ int mvshiftTempHor = mvShift + getComponentScaleX((ComponentID)compID, pu.chromaFormat); int mvshiftTempVer = mvShift + getComponentScaleY((ComponentID)compID, pu.chromaFormat); int leftPixelExtra; if (compID == COMPONENT_Y) { leftPixelExtra = (NTAPS_LUMA >> 1) - 1; } else { leftPixelExtra = (NTAPS_CHROMA >> 1) - 1; } PelBuf &srcBuf = pcPadTemp.bufs[compID]; deltaIntMvX = (cMv.getHor() >> mvshiftTempHor) - (startMv.getHor() >> mvshiftTempHor); deltaIntMvY = (cMv.getVer() >> mvshiftTempVer) - (startMv.getVer() >> mvshiftTempVer); }}} 5. In {{{EncGOP::xFindDistortionPlane()}}} In JVET-H0047, upper limit B_max (i.e. 128 >> chromaShift) equals 64 for 4:2:0 downsampled chroma components and 128 otherwise. {{{ uint64_t EncGOP::xFindDistortionPlane(const CPelBuf& pic0, const CPelBuf& pic1, const uint32_t rshift #if ENABLE_QPA , const uint32_t chromaShift /*= 0*/ #endif ) ... const uint32_t B = Clip3(0, 128 >> chromaShift, 4 * uint32_t(16.0 * sqrt(R) + 0.5)); // WPSNR block size in integer multiple of 4 (for SIMD, = 64 at full-HD) ... sumAct = 16.0 * sqrt ((3840.0 * 2160.0) / double((W << chromaShift) * (H << chromaShift))) * double(1 << BD); }}} should be corrected as following: {{{ uint64_t EncGOP::xFindDistortionPlane(const CPelBuf& pic0, const CPelBuf& pic1, const uint32_t rshift #if ENABLE_QPA , const uint32_t chromaShiftHor /*= 0*/, const uint32_t chromaShiftVer /*= 0*/ #endif ) ... const uint32_t B = Clip3(0, 128 >> chromaShiftVer, 4 * uint32_t(16.0 * sqrt(R) + 0.5)); // WPSNR block size in integer multiple of 4 (for SIMD, = 64 at full-HD) ... sumAct = 16.0 * sqrt ((3840.0 * 2160.0) / double((W << chromaShiftHor) * (H << chromaShiftVer))) * double(1 << BD); }}} " wangyang.cs 683 Encoder fails (core dump) after first picture when using a different coding structure VTM VTM-6.2 defect new 2019-11-12T02:10:47+01:00 2019-11-12T02:10:47+01:00 "When running the encoder with a modified low delay P structure (using only the previous picture for reference), the encoder fails (core dump) after successfully encoding the first (intra) picture. The config file is attached. The output is: VVCSoftware: VTM Encoder Version 6.2 [Linux][GCC 7.4.0][64 bit] [SIMD=AVX2] TOOL CFG: IBD:1 HAD:1 RDQ:1 RDQTS:1 RDpenalty:0 LQP:0 SQP:0 ASR:0 MinSearchWindow:8 RestrictMESampling:0 FEN:1 ECU:0 FDM:1 CFM:0 ESD:0 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:5 BDPCM:0 Slice: M=0 Tiles:1x1 MCTS:0 CIP:0 SAO:1 ALF:1 TransQuantBypassEnabled:0 WPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 DQ:1 SignBitHidingFlag:0 RecalQP:0 NEXT TOOL CFG: LFNST:0 MMVD:1 Affine:1 AffineType:1 PROF:1 SubPuMvp:1+0 DualITree:1 IMV:1 BIO:0 LMChroma:1 CclmCollocatedChroma:0 MTS: 1(intra) 0(inter) SBT:1 ISP:1 SMVD:0 CompositeLTReference:0 GBi:0 GBiFast:0 LADF:0 MHIntra:1 Triangle:0 AllowDisFracMMVD:1 AffineAmvr:0 AffineAmvrEncOpt:0 DMVR:0 MmvdDisNum:6 JointCbCr:1 PLT:0 IBC:0 HashME:0 WrapAround:0 LoopFilterAcrossVirtualBoundaries:0 Reshape:1 (Signal:SDR Opt:0) MIP:1 EncDbOpt:0 FAST TOOL CFG: LCTUFast:1 FastMrg:1 PBIntraFast:1 IMV4PelFast:1 MTSMaxCand: 3(intra) 4(inter) ISPFast:0 AMaxBT:1 E0023FastEnc:1 ContentBasedFastQtbt:0 UseNonLinearAlfLuma:1 UseNonLinearAlfChroma:1 MaxNumAlfAlternativesChroma:8 FastMIP:0 FastLocalDualTree:2 NumSplitThreads:1 NumWppThreads:1+0 EnsureWppBitEqual:0 RPR:0 started @ Mon Nov 11 19:02:04 2019 POC 0 TId: 0 ( I-SLICE, QP 31 ) 64288 bits [Y 35.4756 dB U 38.2585 dB V 38.9203 dB] [ET 18 ] [L0 ] [L1 ] Segmentation fault (core dumped)" rajan_joshi 734 VTM-7.0 has enc/dec mismatch for RPR 1.5x VTM VTM-7.0 defect new 2019-12-01T08:01:18+01:00 2020-01-09T11:41:11+01:00 "Some RPR 1.5x tests have encoder-decoder mismatches. The mismatches occur for either JVET_P0088_P0353_RPR_FILTERS is 0 or 1, so it doesn't seem like related to the filter." luoda 666 FIx the wrong QP and lambda clipping in rate control VTM VTM-7.0rc1 defect new 2019-11-07T13:50:56+01:00 2019-11-07T13:50:56+01:00 "In current VTM, the lambda has been scaled by ""pow(2,bitdepth_luma_scale)"" where {{{ int bitdepth_luma_scale = 2 * (m_encRCSeq->getbitDepth() - 8 - DISTORTION_PRECISION_ADJUSTMENT(m_encRCSeq->getbitDepth())); }}} The scale parameter is 16 when the internal bitdepth is set as 10. But when rate control is applied. The lambda will be estimated by target bits and clipped by the neighbor lambdas. The clip bounds are set manually, which have not been scaled by the bitdepth_luma_scale, leading to wrong QP and lambda clipping. As the example code in ""EncRCPic::estimatePicLambda()"" shown: {{{ lastLevelLambda = Clip3( 0.1, 10000.0, lastLevelLambda ); estLambda = Clip3( lastLevelLambda * pow( 2.0, -3.0/3.0 ), lastLevelLambda * pow( 2.0, 3.0/3.0 ), estLambda ); }}} which means that the estLambda will be clipped by 20000, while the QP will be calculated from estLambda as following: {{{ QP=int(4.2005 * log(lambda / pow(2.0, bitdepth_luma_scale)) + 13.7122 + 0.5); }}} the max QP will be no more than 44 due to the wrong clip bound at the low bitrate cases. Fix it by scaling all the clip bounds by the pow(2,bitdepth_luma_scale)." lzz8246 793 Mismatch encode decode for YUV400 VTM VTM-7.1 defect new 2020-01-03T09:13:13+01:00 2020-07-12T17:41:48+02:00 "The VTM raises an error Exceeded FIFO size reading bitstream. My source is cloned at the commit bd9038ff700ff886f23fc1834f24ef7c1dec66b8, branch master. Notes: + My built VTM decoder works well on YUV420. + HM (HEVC) decoder can decode the bitstream of YUV400 source but the VTM decoder. {{{ ./EncoderAppStatic -i ./test.yuv -b ./test_enc_400.vvc -o ./recon_from_enc_400.yuv --InputBitDepth=8 --OutputBitDepth=8 --InputChromaFormat=400 -fr 15 -wdt 640 -hgt 360 -c ../cfg/encoder_intra_vtm.cfg -q 37 -f 1 **************************************************************************** ** WARNING: --JointCbCr has been disabled because the chromaFormat is 400 ** **************************************************************************** TOOL CFG: IBD:1 HAD:1 RDQ:1 RDQTS:1 RDpenalty:0 LQP:0 SQP:0 ASR:0 MinSearchWindow:8 RestrictMESampling:0 FEN:1 ECU:0 FDM:1 CFM:0 ESD:0 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:5 ChromaTS:1 BDPCM:0 Tiles: 1x1 Slices: 1 MCTS:0 SAO:1 ALF:1 WPP:0 WPB:0 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 DQ:1 SignBitHidingFlag:0 RecalQP:0 NEXT TOOL CFG: LFNST:1 MMVD:1 Affine:1 AffineType:1 PROF:0 SubPuMvp:1+0 DualITree:1 IMV:1 BIO:0 LMChroma:1 HorCollocatedChroma:1 VerCollocatedChroma:0 MTS: 1(intra) 0(inter) SBT:1 ISP:1 SMVD:0 CompositeLTReference:0 Bcw:0 BcwFast:0 LADF:0 CIIP:0 Triangle:0 AllowDisFracMMVD:1 AffineAmvr:0 AffineAmvrEncOpt:0 DMVR:0 MmvdDisNum:8 JointCbCr:0ACT:0 PLT:0 IBC:0 HashME:0 WrapAround:0 LoopFilterAcrossVirtualBoundaries:0 Reshape:1 (Signal:SDR Opt:0 CSoffset:2) MRL:1 MIP:1 EncDbOpt:0 FAST TOOL CFG: LCTUFast:1 FastMrg:1 PBIntraFast:1 IMV4PelFast:1 MTSMaxCand: 4(intra) 4(inter) ISPFast:1 FastLFNST:1 AMaxBT:1 E0023FastEnc:1 ContentBasedFastQtbt:0 UseNonLinearAlfLuma:1 UseNonLinearAlfChroma:1 MaxNumAlfAlternativesChroma:8 FastMIP:1 FastLocalDualTree:0 NumSplitThreads:1 NumWppThreads:1+0 EnsureWppBitEqual:0 RPR:0 TemporalFilter:0 ... ... ./DecoderAppStatic -b ./test_enc_400.vvc -o recon_from_dec_400.yuv VVCSoftware: VTM Decoder Version 7.1 [Linux][GCC 5.4.0][64 bit] [SIMD=AVX2] ERROR: In function ""read"" in ..../VVCSoftware_VTM/source/Lib/CommonLib/BitStream.cpp:293: Exceeded FIFO size }}}" minhmanho 814 Encoder/Decoder mismatch found in RA configuration when decoding concatenate bitstreams VTM VTM-7.1 defect new 2020-01-19T16:44:59+01:00 2020-07-12T17:41:48+02:00 "There is no mismatch when decoding Individual bitstreams but mismatches found when decoding concatenated bitstream. Encoder command line for chunk 0 is: bin/EncoderAppStatic -c cfg/encoder_randomaccess_vtm.cfg -c cfg/per-sequence/../per-class/classF.cfg -c cfg/per-sequence/../444/yuv444.cfg -c cfg/per-sequence/WebBrowsing_444.cfg --IBC=1 --PLT=1 --BDPCM=2 --HashME=1 --TileUniformSpacing=1 --UniformTileColsWidthMinus1=0 --UniformTileRowHeightMinus1=0 --SEIDecodedPictureHash=1 --PrintHexPSNR=1 --FramesToBeEncoded=33 --IntraPeriod=32 --FrameSkip=0 -q 22 --InputFile=/home/admin/local_sequences/sc_web_browsing_1280x720_30_8bit_300_444_r1.yuv -b WebBrowsing444_QP22_rap0.bin -o '' " luoda 880 Bug: In setting POC for dependent layers in DecLib.cpp VTM VTM-7.3 defect new 2020-02-12T13:04:37+01:00 2020-02-12T13:04:37+01:00 "The setting of POC for pictures in dependent layers checks only the Reference pictures in List 0 against the pictures in the same Access Unit. Update to include the checks for pictures in both Reference List 0 and List 1 against the pictures in the same Access Unit. " kashyapkammachisreedhar 913 Invalid LevelIDC in DCI for multi-layer VTM VTM-8.0 defect new 2020-03-02T16:42:29+01:00 2020-03-02T16:42:29+01:00 "I'm running the encoder with the parameters: {{{ EncoderApp -c ../cfg/encoder_randomaccess_vtm.cfg -c ../cfg/layers.cfg -l0 -c ../cfg/per-sequence/RaceHorses.cfg -l1 -c ../cfg/per-sequence/RaceHorsesC.cfg }}} This contains the following level configuration: layers.cfg: LevelPTL1 : 6.2 RaceHorses.cfg: Level : 2 RaceHorsesC.cfg: Level : 3 The coded bitstreams contains the following level IDCs: DCI: 2 VPS: 3, 6.2 SPS id0: 2 SPS id1: 3 DCI is apparently set to the level of the base layer, but it should be the highest level in the bitstream. After checking for DCI constraints was added, the decoder fails when decoding the second SPS." ksuehring 929 Encoder hangs when too few frames in source file VTM VTM-8.0 defect new 2020-03-05T18:53:08+01:00 2020-03-05T18:53:08+01:00 "If the encoder is unable to read a frame from the source video file due to EOF, it hangs (goes in an endless loop). A quick way to demonstrate this is: ./bin/EncoderAppStatic -c cfg/encoder_intra_vtm.cfg -c cfg/per-sequence/BasketballPass.cfg -fs 499 -f 3 --TemporalSubsampleRatio=1 Possible fix might be: EncApp.cpp:1100:encodePrep(...) Change return keepDoing; to return keepDoing && !eos; EncLib.cpp:799:encode(...) Add if (!m_iNumPicRcvd) { return false; } to the start of the function. EncLib.cpp:926:encode(...) Add if (!m_iNumPicRcvd) { return false; } to the start of the function. " karlsharman 959 Coding loss of LMCS with Kimono 420 VTM VTM-8.0 defect new 2020-03-19T03:41:57+01:00 2020-03-24T18:59:19+01:00 "LMCS has coding loss with Kimono420 test sequences on top of VTM-8. The anchor is VTM-8 with LMCS on, and the Test is VTM-8 with LMCS off. The coding performance for Kimono420 is shown as follows. AI: 0.01% -0.27% -0.31% RA: -2.53% 2.95% 6.61% LB: -0.23% 1.34% 0.19% When dual tree is DISABLE, the qualilty drop is also shown as follows AI: -0.42% 1.70% 2.06% RA: -3.03% 4.78% 9.71% LB: -0.19% 1.83% 0.64% " lienfei.chen 977 writing outside of allocated memory VTM VTM-8.0 defect new 2020-03-25T04:29:00+01:00 2020-03-25T04:34:42+01:00 "InterPrediction.cpp line 185: m_filteredBlockTmp[i][c] = ( Pel* ) xMalloc( Pel, ( extWidth + 4 ) * ( extHeight + 7 + 4 ) ); This temporal block is allocated with size 152x144 with no specified stride, but is used with stride equal to 512 in xPredInterBlk() (line 792). Cause stride is derived from dstBuf.stride. If I understand right dstBuf is allocated as 128x128 pixels in quaterpel dimension, so real size of dstBuf is 512x512. But m_filteredBlockTmp is only in real pixels dimension. And that is followed by writing out of allocated memory in some cases. Please see attached stream." VChemezov 981 Mismatch when slice_ts_residual_coding_disabled_flag is enabled VTM VTM-8.0 defect reopened 2020-03-26T09:21:00+01:00 2020-07-12T17:41:48+02:00 "If slice_ts_residual_coding_disabled_flag is enabled, encoder / decoder mismatch occurs when sign data hiding (SDH) is enabled. When slice_ts_residual_coding_disabled_flag is enabled, RRC shall be used instead of TSRC in transfrom skip case. However, encoder RD search does not seem to use RRC in TS case (from line 530 in QuantRDOQ.cpp). A merge requeset will be submitted (based on an attached patch). Note: In lossless case, the above RD and SDH are not used (thus enc-dec mismatch doesn't occur). It seems BDPCM encoder still uses TSRC in RD search even if slice_ts_residual_coding_disabled_flag is enabled, but the above fix doesn't cover this case. Thus if BDPCM, RRC (slice_ts_residual_coding_disabled_flag is 1) and SDH are enabled, some encoder mismatch still occurs with the fix. " T.Hashimoto 988 Decoder mismatch for lossless coding when RDOQ is enabled at config VTM VTM-8.0 defect new 2020-04-01T02:20:30+02:00 2020-07-12T17:41:48+02:00 "There is an encode/decode mismatch that occurs with lossless coding when RDOQ is enabled at the config level. This happens for certain frames for AI, RA and LDB configurations. An example is provided below for AI: EncoderAppStatic -c encoder_intra_vtm.cfg -c ArenaOfValor.cfg -f 100 -ip 1 -q 0 -ts 8 -c lossless.cfg --IBC=1 --HashME=1 --DepQuant=1 --RDOQ=1 --RDOQTS=1 -b str.bin -o /dev/null -fs 0 It also appears that certain frames are being lossy coded due to this bug whereas certain frames are still lossless. A patch is provided here which prevents lossless coding from going into RDOQ for lossless. This solves the bug. A merge request will be done for this fix. " analci 1104 Inconsistency between two rate-distortion costs in the case of a I-slice in 4:0:0 VTM VTM-8.0 defect new 2020-06-05T22:22:08+02:00 2020-06-05T22:22:08+02:00 "Change in the code of VTM-8.0 ----------------------------- In the file ""IntraSearch.cpp"", in the method `IntraSearch::xGetIntraFracBitsQT`, at line 3299, `cu.isSepTree()` should be replaced by `cs.slice->isIntra()`. Explanation ----------- For a given luminance Coding Block (CB), for a given transform to be tested (e.g. `trGrpIdx` = 0, `cu.mtsFlag` = 1, `cu.lfnstIdx` = 0), in `IntraSearch::estIntraPredLumaQT`, once a list of intra prediction modes to be tested for full rate-distortion is created, the best intra prediction mode in terms of rate-distortion among those in this list is searched. The rate-distortion cost involved in the search is named `csTemp->cost` at line 1145 in the file ""IntraSearch.cpp"" (this rate-distortion cost is called ""first"" rate-distortion cost). The rate component of the first rate-distortion cost is computed via the method `IntraSearch::xGetIntraFracBitsQT` in the file ""IntraSearch.cpp"". Now, let us consider another rate-distortion cost to complete the explanation. For a given luminance CB, in `EncCu::xCheckRDCostIntra`, the best set of transforms in terms of rate-distortion is searched. In the search, each test corresponds to a different set of transforms, each test already having the best intra prediction mode in terms of rate-distortion for its set of transform. The rate-distortion cost involved in the search is named `tempCS->cost` at line 1906 in the file ""EncCu.cpp"" (this rate-distortion cost is called ""second"" rate-distortion cost). The rate component of the second rate-distortion cost is computed from line 1878 to line 1905 in the file ""EncCu.cpp"". Note that, in the explanation, we omit that the rate component of the second rate-distortion cost can be modified by the subsequent calls to `EncCu::xEncodeDontSplit`, `EncCu::xCheckDQP`, and `EncCu::xCheckChromaQPOffset` as this does not impact the purpose of the ticket. The problem is that, for a I-slice in 4:0:0, the rate component of the first rate-distortion cost is sometimes not equal to the rate component of the second rate-distortion cost. Indeed, at line 3299 in the file ""IntraSearch.cpp"", `cu.isSepTree()` is false, hence removing the cost of LFNST from the rate component of the first rate-distortion cost. The problem does not appear in the case of a I-slice in 4:2:0 as `cu.isSepTree()` is true (using the standard configuration file), thus including the cost of LFNST in the rate component of the first rate-distortion cost. For the same reason, the problem does not appear in 4:4:4. Rate-distortion performance --------------------------- On the first frame of each sequence of the CTC, in 4:0:0, in all-intra, VTM-8.0 with the above-mentioned modification gives -0.023% with respect to VTM-8.0. There is no change in running time, neither the encoder nor the decoder. " dumas 1034 Duplicated functions for writing/parsing of prediction weight table VTM VTM-8.1 enhancement new 2020-04-30T11:35:42+02:00 2020-07-29T19:56:06+02:00 "Prediction weight table reading and parsing uses different functions for parsing and writing depending on the location in PH or SH, although the same syntax table in the specification text is referenced in both locations in the spec text: {{{ void parsePredWeightTable( Slice* pcSlice, const SPS *sps ); void parsePredWeightTable ( PicHeader *picHeader, const SPS *sps ); }}} {{{ void xCodePredWeightTable ( Slice* pcSlice ); void xCodePredWeightTable ( PicHeader *picHeader, const SPS *sps ); }}} Code should be refactored to avoid duplication. Cleanup for variable naming is needed as well." ksuehring 1223 Function problem for 10bit VTM VTM-9.3 defect new 2020-07-23T11:12:30+02:00 2020-07-24T08:30:39+02:00 "For 8bit photos the codec works. For 10bit it doesn't work anymore. What function is invariant for 10bit. {{{ if (!m_lmcsEnabled && m_sampleRange == 1 && m_matrixCoefficients == 0 && m_useColorTrans && m_iQP == 0) { if (m_costMode == COST_STANDARD_LOSSY || m_costMode == COST_MIXED_LOSSLESS_LOSSY_CODING) { msg( VERBOSE, ""NearbyLossless < ""); } if (m_costMode == COST_LOSSLESS_CODING) { msg( VERBOSE, ""Lossless < ""); } } }}} EncoderApp_360.exe --SummaryVerboseness --InputFile=117.yuv --BitstreamFile=image.vvc --SourceWidth=1564 --SourceHeight=1558 --FrameRate=25.000 --InputBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 '''--MatrixCoefficients=0''' --InputColorPrimaries=-1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=1 --HashME=1 --IBC=1 --DecodingRefreshType=1 --Profile=auto --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 '''--CostMode=lossless''' --InputChromaFormat=444 --ChromaFormatIDC=444 '''--QP=0''' --BDPCM=1 '''--ColorTransform=1''' '''--VideoFullRange=1''' --ChromaTS=1 --DepQuant=0 '''--LMCSEnable=0''' --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=0 --LFNST=0 --JointCbCr=0 --LoopFilterDisable=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --InternalBitDepth=0 --IntraPeriod=1 --GOPSize=1 --SearchRange=64 --QpInValCb=""17 22 34 42"" --QpOutValCb=""17 23 35 39"" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=1 --IntraConstraintFlag=1 --Level=15.5 --Tier=high --RateControl=0 --SEIDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --SubPuMvp=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1 --VerCollocatedChroma=1" Jamaika 1285 Cleanup of some variable names VTM VTM-9.3 enhancement new 2020-08-03T03:50:23+02:00 2020-08-03T04:04:51+02:00 "There are some variable names may need to be changed considering their actual meanings, such as rightPixel, belowPixel, rightSign, belowSign in transform skip residual coding related functions. rightPixel-->leftPixel belowPixel-->abovePixel rightSign-->leftSign belowSign-->aboveSign " yjpiao