__group__ ticket summary component version type owner status created _changetime _description _reporter H.266/VVC v3 1629 mtt_split_cu_vertical_flag context uses undefined variable chType spec H.266/VVC v3 defect new 2024-01-25T11:46:56+01:00 2025-10-30T04:01:37+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 H.266/VVC v3 1650 incorrect indexing for the h location component in ALF process spec H.266/VVC v3 defect new 2024-11-08T13:27:21+01:00 2025-10-29T23:10:41+01:00 "In text of ISO/IEC FDIS 23090-3 :202x (2nd Ed.) (E) (Date: 2022-04-02): In 8.8.5.2, incorrect indexing for the h component. The index should be (x+i) and not (x+i,y+j): - The locations ( hx + i , vy + j ) for each of the corresponding luma samples… - Same modification should be made for the equations (1438),(1440),(1441). In 8.8.5.3, the same modification should be made: - The location ( hx4 + i , vy4 + j ) is modified by invoking the ALF sample padding… - Same modification should be made for the equations (1446),(1447),(1448),(1449) In 8.8.5.4, the same modification should be made: - The locations ( hx + i , vy + j ) for each of the corresponding chroma samples… - The location ( hx + i , vy + j ) is modified by invoking the ALF sample padding… - Same modification should be made for the equations (1477),(1482) In 8.8.5.7, the same modification should be made: - The luma locations ( hx + i , vy + j ) with i = −1..1, j = −1..2 inside… - The location ( hx + i , vy + j ) is modified by invoking the ALF sample padding… - Same modification should be made for the equations (1503),(1507) " bordes VTM-10.0 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 VTM-10.0 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 VTM-10.0 1391 Unnecessary setting of mrgTypeNeighbours in getInterMergeCandidates() and checking condition in getInterMMVDMergeCandidates() VTM VTM-10.0 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 VTM-10.0 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 VTM-10.0 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 VTM-10.2 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 VTM-12.0 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 VTM-12.0 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 VTM-12.0 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 VTM-17.2 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 VTM-18.2 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 VTM-18.2 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 VTM-19.0 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 VTM-19.0 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 VTM-19.0 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 VTM-21.0 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 VTM-21.0 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 VTM-21.0 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 VTM-21.2 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 VTM-23.0 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 VTM-23.0 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 VTM-23.0 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 VTM-23.0 1639 Compatibility issue with RPR and multi-pass VTM VTM-23.0 defect new 2024-05-28T08:30:57+02:00 2024-05-28T08:30:57+02:00 "Cconfiguration (debug mode): {{{ -c .\cfg\encoder_lowdelay_P_vtm.cfg -c .\cfg\per-sequence\RaceHorses.cfg -c test.cfg -q 51 -i D:\Videos\ctc\sdr\RaceHorses_416x240_30.yuv }}} test.cfg: {{{ RPR : 1 ScalingRatioHor : 0.5 ScalingRatioVer : 0.5 DeltaQpRD : 1 # an existing multi-pass implementation }}} Log: {{{ VVCSoftware: VTM Encoder Version 23.0 [Windows][VS 1916][64 bit] [SIMD=AVX2] TOOL CFG: IBD:1 HAD:1 RDQ:1 RDQTS:1 RDpenalty:0 LQP:0 SQP:1 ASR:0 MinSearchWindow:8 RestrictMESampling:0 FEN:1 ECU:0 FDM:1 ESD:0 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:5 ChromaTS:1 BDPCM:0 Tiles: 1x1 Slices: 1 MCTS:0 SAO:1 ALF:1 CCALF:1 MaxNumALFAPS 8 AlfapsIDShift 0 ConstantJointCbCrSignFlagWPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 DQ:1 SignBitHidingFlag:0 RecalQP:0 TOOL CFG: LFNST:0 MMVD:1 Affine:1 AffineType:1 AdaptBypassAffineMe:0 PROF:1 SbTMVP:1 DualITree:1 IMV:1 BIO:0 LMChroma:1 HorCollocatedChroma:1 VerCollocatedChroma:0 MTS:1(explicit intra) SBT:1 ISP:1 SMVD:0 CompositeLTReference:0 Bcw:0 BcwFast:0 LADF:0 CIIP:1 Geo:0 AllowDisFracMMVD:1 AffineAmvr:0 AffineAmvrEncOpt:0 AffineAmvp:1 DMVR:0 MmvdDisNum:6 JointCbCr:1 ACT:0 PLT:0 IBC:0 HashME:0 WrapAround:0 VirtualBoundariesEnabledFlag:0 VirtualBoundariesPresentInSPSFlag:1 vertical virtual boundaries:[ ] horizontal virtual boundaries:[ ] Reshape:1 (Signal:SDR Opt:0 CSoffset:1) MRL:1 MIP:0 EncDbOpt:1 AlfLambdaOpt:0 FAST TOOL CFG: LCTUFast:1 FastMrg:1 MaxMergeRdCandNumTotal:5 MergeRdCandQuotaRegular:4 MergeRdCandQuotaRegularSmallBlk:4 MergeRdCandQuotaSubBlk:2 MergeRdCandQuotaCiip:1 MergeRdCandQuotaGpm:8 PBIntraFast:1 IMV4PelFast:1 MTSMaxCand: 3(intra) 4(inter) ISPFast:0 AMaxBT:1 E0023FastEnc:1 ContentBasedFastQtbt:0 UseNonLinearAlfLuma:1 UseNonLinearAlfChroma:1 MaxNumAlfAlternativesChroma:8 TTFastSkip:31 TTFastSkipThr:1.075 FastLocalDualTree:2 RPR:(0.50x, 0.50x)|8 TemporalFilter:4/0 SEI CTI:0 BIM:0 SEI FGC:0 SEI processing Order:0 started @ Tue May 28 11:25:42 2024 POC 0 LId: 0 TId: 0 ( IDR_N_LP, I-SLICE, QP 49 ) 6928 bits [Y 24.2190 dB U 30.0202 dB V 29.6330 dB] [ET 95 ] [L0] [L1] [Y2 24.2190 dB U2 30.0202 dB V2 29.6330 dB] MS-SSIM2: [Y 0.8330 U 0.8368 V 0.8459 ] POC 1 LId: 0 TId: 0 ( TRAIL, P-SLICE, QP 59 ) 392 bits [Y 23.0364 dB U 29.4621 dB V 29.4429 dB] [ET 43 ] [L0 0c] [L1] [Y2 23.0364 dB U2 29.4621 dB V2 29.4429 dB] MS-SSIM2: [Y 0.8027 U 0.8338 V 0.8417 ] POC 2 LId: 0 TId: 0 ( TRAIL, P-SLICE, QP 57 ) 488 bits [Y 22.7106 dB U 29.2681 dB V 29.2180 dB] [ET 44 ] [L0 1c 0] [L1] [Y2 22.7106 dB U2 29.2681 dB V2 29.2180 dB] MS-SSIM2: [Y 0.7838 U 0.8191 V 0.8325 ] POC 3 LId: 0 TId: 0 ( TRAIL, P-SLICE, QP 59 ) 296 bits [Y 22.0643 dB U 29.0028 dB V 28.7595 dB] [ET 45 ] [L0 2c 1 0] [L1] [Y2 22.0643 dB U2 29.0028 dB V2 28.7595 dB] MS-SSIM2: [Y 0.7540 U 0.8171 V 0.8243 ] POC 4 LId: 0 TId: 0 ( TRAIL, P-SLICE, QP 57 ) 440 bits [Y 22.0757 dB U 28.7336 dB V 28.3748 dB] [ET 56 ] [L0 3c 2 1 0] [L1] [Y2 22.0757 dB U2 28.7336 dB V2 28.3748 dB] MS-SSIM2: [Y 0.7498 U 0.8207 V 0.8203 ] POC 5 LId: 0 TId: 0 ( TRAIL, P-SLICE, QP 58 ) 328 bits [Y 21.6893 dB U 28.1559 dB V 27.9490 dB] [ET 52 ] [L0 4c 3 2 0] [L1] [Y2 21.6893 dB U2 28.1559 dB V2 27.9490 dB] MS-SSIM2: [Y 0.7316 U 0.8078 V 0.8107 ] POC 6 LId: 0 TId: 0 ( TRAIL, P-SLICE, QP 58 ) 456 bits [Y 21.7201 dB U 27.9105 dB V 28.3760 dB] [ET 66 ] [L0 5c 4 3 0] [L1] [Y2 21.7201 dB U2 27.9105 dB V2 28.3760 dB] MS-SSIM2: [Y 0.7228 U 0.8062 V 0.8037 ] POC 7 LId: 0 TId: 0 ( TRAIL, P-SLICE, QP 58 ) 296 bits [Y 21.3288 dB U 27.5122 dB V 28.2781 dB] [ET 54 ] [L0 6c 5 4 0] [L1] [Y2 21.3288 dB U2 27.5122 dB V2 28.2781 dB] MS-SSIM2: [Y 0.7025 U 0.7972 V 0.7994 ] D:\VTM-23.0\bin\vs15\msvc-19.16\x86_64\debug\EncoderApp.exe (进程 36964)已退出，返回代码为: -1。 }}} Error: {{{ CHECKD(rsAddr(blk.bottomRight(), r.stride) >= ((r.height - 1) * r.stride + r.width), ""Trying to access a buf outside of bound!""); EncoderApp.exe!PelStorage::getBuf(const CompArea & blk) 行 978 C++ EncoderApp.exe!EncCu::xCalDebCost(CodingStructure & cs, Partitioner & partitioner, bool calDist) 行 3867 C++ EncoderApp.exe!EncCu::xCheckRDCostUnifiedMerge(CodingStructure * & tempCS, CodingStructure * & bestCS, Partitioner & partitioner, const EncTestMode & encTestMode) 行 2445 C++ EncoderApp.exe!EncCu::xCompressCU(CodingStructure * & tempCS, CodingStructure * & bestCS, Partitioner & partitioner, double maxCostAllowed) 行 791 C++ EncoderApp.exe!EncCu::compressCtu(CodingStructure & cs, const UnitArea & area, const unsigned int ctuRsAddr, const EnumArray & prevQP, const EnumArray & currQP) 行 288 C++ EncoderApp.exe!EncSlice::encodeCtus(Picture * pcPic, const bool bCompressEntireSlice, const bool bFastDeltaQP, EncLib * pEncLib) 行 1900 C++ EncoderApp.exe!EncSlice::compressSlice(Picture * pcPic, const bool bCompressEntireSlice, const bool bFastDeltaQP) 行 1563 C++ EncoderApp.exe!EncSlice::precompressSlice(Picture * pcPic) 行 1391 C++ EncoderApp.exe!EncGOP::compressGOP(int pocLast, int numPicRcvd, std::list > & rcListPic, std::list *,std::allocator *> > & rcListPicYuvRecOut, bool isField, bool isTff, const InputColourSpaceConversion snr_conversion, const bool printFrameMSE, bool printMSSSIM, bool isEncodeLtRef, const int picIdInGOP) 行 3505 C++ EncoderApp.exe!EncLib::encode(const InputColourSpaceConversion snrCSC, std::list *,std::allocator *> > & rcListPicYuvRecOut, int & numEncoded) 行 899 C++ EncoderApp.exe!EncApp::encode() 行 1820 C++ EncoderApp.exe!main(int argc, char * * argv) 行 329 C++ }}}" cjj490168650 VTM-23.0 1640 Bug in SEIReader::getSEIDecodingUnitInfoDuiIdx() VTM VTM-23.0 defect new 2024-05-30T18:10:58+02:00 2024-05-30T18:10:58+02:00 "Following commit 2473e511, changes were done to getSEIDecodingUnitInfoDuiIdx() to be able to reuse that function in xParseSEIScalableNesting(). The getSEIDecodingUnitInfoDuiIdx() receives a InputBitstream *bs pointer to the current bitstream, but the *bs parameter is overriden with {{{ InputBitstream* bs = getBitstream(); }}} This causes the decoding unit SEI to not be parsed correctly. The redefinition of the bs parameter should, in my opinion, be deleted." emora VTM-23.0 1641 Compilation error in VS2017 when RExt__HIGH_BIT_DEPTH_SUPPORT is set to 1 VTM VTM-23.0 defect new 2024-06-04T14:39:05+02:00 2024-06-04T14:39:05+02:00 "The VS2017 compiler emits a warning which is considered as an error at line 480 in Quant.cpp when RExt_HIGH_BIT_DEPTH_SUPPORT is enabled in TypeDef.h {{{ const Intermediate_Int iCoeffQ = (Intermediate_Int(clipQCoef) * scale) * (1 << leftShift); }}} The warning says: '''result of 32-bit shift implicitly converted to 64 bits''' I would suggest the following to avoid the warning and be able to compile successfully {{{ const Intermediate_Int iCoeffQ = (Intermediate_Int(clipQCoef) * scale) * (Intermediate_Int(1) << leftShift); }}} " emora VTM-23.0 1642 SIMD code for ALF classification does not match C code VTM VTM-23.0 defect new 2024-06-04T14:54:00+02:00 2024-06-04T14:54:00+02:00 "The simdDeriveClassificationBlk_HBD() function does not match the deriveClassificationBlk() function. This condition: {{{ if( (uint32_t)d1 * (uint32_t)hv0 > (uint32_t)hv1 * (uint32_t)d0 ) }}} has been modified to: {{{ if( (uint64_t)d1 * (uint64_t)hv0 > (uint64_t)hv1 * (uint64_t)d0 ) }}} when RExt_HIGH_BIT_DEPTH_SUPPORT is enabled. However the corresponding SIMD code does not reflect this modification as _mm_mullo_epi32(d1, hv0) or _mm_mullo_epi32(hv1, d0) will only retain the first 32 bits of the multiplication result. {{{ __m128i a = _mm_xor_si128(_mm_mullo_epi32(d1, hv0), _mm_set1_epi32(0x80000000)); __m128i b = _mm_xor_si128(_mm_mullo_epi32(hv1, d0), _mm_set1_epi32(0x80000000)); }}} " emora VTM-3.0 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 VTM-3.0 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 VTM-3.0 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 VTM-4.0 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 VTM-4.0 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 VTM-4.0.1 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 VTM-5.0 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 VTM-5.0 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 VTM-5.0rc1 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 VTM-6.0 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 VTM-6.0 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 VTM-6.1 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 VTM-6.1 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 VTM-6.1 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 VTM-6.1 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 VTM-6.1 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 VTM-6.1 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 VTM-6.1 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 VTM-6.1 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 VTM-6.1 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 VTM-6.2 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 VTM-6.2 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 VTM-6.2 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 VTM-7.0 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 VTM-7.0rc1 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 VTM-7.1 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 VTM-7.1 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 VTM-7.3 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 VTM-8.0 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 VTM-8.0 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 VTM-8.0 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 VTM-8.0 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 VTM-8.0 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 VTM-8.0 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 VTM-8.0 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 VTM-8.1 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 VTM-9.3 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 VTM-9.3 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 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 1645 [misalignment] sbtmvp eanbling condition in CU level VTM defect new 2024-10-22T06:41:10+02:00 2024-10-22T06:41:10+02:00 "in SPEC, the subclause 8.5.5.2 describe the sbTMVP is allowed when sps_sbtmvp_enabled_flag is equal to 1. but in VTM, there are additional condition which is coming from JVET-L0293 (CPR related) {{{ #!div style=""font-size: 80%"" getAffineMergeCnad() function: {{{#!c++ bool sbTmvpEnableFlag = slice.getSPS()->getSbTMVPEnabledFlag() && !(slice.getPOC() == slice.getRefPic(REF_PIC_LIST_0, 0)->getPOC() && slice.isIRAP()); }}} }}} from this condition, SPEC and VTM behave differently in certain case. 1. in case of that current Picture is IRAP and also reference picture is IRAP, SPEC allows sbTMVP but VTM disallows sbTMVP 2. in case of that current picture is POC ""A"" and also reference picture in reference CLVS is POC ""A"", SPEC allows sbTMVP but VTM disallows sbTMVP CPR is replace to IBC as separate prediction mode, we don't need to keep this additional condition in VTM. " hmjang 1646 [misalignment] condition to use of tempMV from sbtmvp candidate VTM defect new 2024-10-22T06:53:50+02:00 2024-10-22T06:53:50+02:00 "in the SPEC subclause 8.5.5.4, tempMV from spatial A1 neighbor is used to adjust the position in colpic. during this process, condition check is described as below When availableFlagA1 is equal to TRUE, the following applies: – If all of the following conditions are true, tempMv is set equal to mvL0A1: – predFlagL0A1 is equal to 1, – DiffPicOrderCnt( ColPic, RefPicList[ 0 ][ refIdxL0A1 ] ) is equal to 0, – Otherwise, if all of the following conditions are true, tempMv is set equal to mvL1A1: – sh_slice_type is equal to B, – predFlagL1A1 is equal to 1, – DiffPicOrderCnt( ColPic, RefPicList[ 1 ][ refIdxL1A1 ] ) is equal to 0. but in the VTM, they check if the those pictures are physically same. Therefore, in case of multilayer, we can imagine that current picture is layer 2, reference picture of A1 is Layer 1 and colpic is Layer 0 with same POC, tempMV is not used from the VTM but SPEC allow to use it. {{{ def getInterMergeSubPuMvpCand(): if ((mrgCtx.interDirNeighbours[0] & (1 << REF_PIC_LIST_0)) && slice.getRefPic(REF_PIC_LIST_0, mrgCtx.mvFieldNeighbours[0][REF_PIC_LIST_0].refIdx) == pColPic) { cTMv = mrgCtx.mvFieldNeighbours[0][REF_PIC_LIST_0].mv; #if GDR_ENABLED if (isEncodeGdrClean) { isSubPuSolid[REF_PIC_LIST_0] = mrgCtx.mvSolid[0][REF_PIC_LIST_0]; } #endif } else if (slice.isInterB() && (mrgCtx.interDirNeighbours[0] & (1 << REF_PIC_LIST_1)) && slice.getRefPic(REF_PIC_LIST_1, mrgCtx.mvFieldNeighbours[0][REF_PIC_LIST_1].refIdx) == pColPic) { cTMv = mrgCtx.mvFieldNeighbours[0][REF_PIC_LIST_1].mv; #if GDR_ENABLED if (isEncodeGdrClean) { isSubPuSolid[REF_PIC_LIST_1] = mrgCtx.mvSolid[0][REF_PIC_LIST_1]; } #endif } }}} " hmjang 1647 [misalignment] pruning condition for AMVP HMVP candidate VTM defect new 2024-10-22T07:01:20+02:00 2024-10-22T07:12:43+02:00 "in the SPEC subclause 8.5.2.9. it is describe that HMVP candidate is added in the list only in case of its reference picture is physically same with reference picture pointed by signaled reference index. When the reference picture corresponding to the reference index of the history-based motion vector predictor candidate HmvpCandList[ i − 1 ] in the RPL LY is the '''same as the reference picture''' corresponding to reference index refIdxLX in the RPL LX, the following applies: –The rounding process for motion vectors as specified in clause 8.5.2.14 is invoked with mvX set equal to the LY motion vector of the candidate HmvpCandList[ i − 1 ], rightShift set equal to AmvrShift, and leftShift set equal to AmvrShift as inputs and the rounded LY motion vector of the candidate HmvpCandList[ i − 1 ] as output is assigned to mvpListLX[ numCurrMvpCand++ ]. but VTM only check the difference of POC between current reference picture and reference picture of HMVP candidate. {{{ #!div style=""font-size: 80%"" addAMVPHMVPCand() function: {{{#!c++ if (neibRefIdx >= 0 && (CU::isIBC(*pu.cu) || (currRefPOC == slice.getRefPOC(eRefPicListIndex, neibRefIdx)))) }}} }}} therefore, if the HMVP candidate's reference picture has same POC with reference picture but is in different layer, SPEC disallow to add it but VTM allow it. " hmjang 1648 [misalignment] on use of sps_chroma_horizontal/vertical_collocated_flag VTM defect new 2024-10-22T07:08:19+02:00 2024-10-22T07:08:19+02:00 "SPEC subclause 8.5.6.3.1 sps level chroma phase information is used to derive pixel position inside of reference picture for motion compensation. during this process, it is written that information is from SPS which current picture refer to. addX = sps_chroma_horizontal_collocated_flag ? 0 : 8 * ( scalingRatio[ 0 ] − ( 1 << 14 ) ) (903) addY = sps_chroma_vertical_collocated_flag ? 0 : 8 * ( scalingRatio[ 1 ] − ( 1 << 14 ) ) (904) but in the VTM, those information is from SPS which reference picture is refer to. int addX = isLuma(compID) ? 0 : int(1 - refPic->cs->sps->getHorCollocatedChromaFlag()) * 8 * (scalingRatio.x - SCALE_1X.x); int addY = isLuma(compID) ? 0 : int(1 - refPic->cs->sps->getVerCollocatedChromaFlag()) * 8 * (scalingRatio.y - SCALE_1X.y); in case of single layer, SPS information is same between reference picture and current picture but in the multilayer case, each CLVS can refer own SPS. it means those information can be different between reference picture and current picture. so VTM should be fixed to use it from current picture's SPS. " hmjang 1649 [misalignment] on rprConstraintsActiveFlag VTM defect new 2024-10-22T07:12:02+02:00 2024-11-06T13:43:38+01:00 "SPEC describe the equation to derive rprConstraintsActiveFlag as below RprConstraintsActiveFlag[ i ][ j ] = ( pps_pic_width_in_luma_samples != refPicWidth | | pps_pic_height_in_luma_samples != refPicHeight | | pps_scaling_win_left_offset != refScalingWinLeftOffset | | pps_scaling_win_right_offset != refScalingWinRightOffset | | pps_scaling_win_top_offset != refScalingWinTopOffset | | pps_scaling_win_bottom_offset != refScalingWinBottomOffset | | '''sps_num_subpics_minus1 != fRefNumSubpics''' ) but in the VTM, the last condition is missed. {{{ bool isRefScaled(const PPS* pps) const { return unscaledPic->getPicWidthInLumaSamples() != pps->getPicWidthInLumaSamples() || unscaledPic->getPicHeightInLumaSamples() != pps->getPicHeightInLumaSamples() || unscaledPic->getScalingWindow() != pps->getScalingWindow(); } }}} in case of single layer, SPS information is same between picture, but in multilayer profile, each CLVS can have own SPS, so the number of subpictures can be different between current picture and reference picture. VTM should be fixed to consider this also as same as SPEC. " hmjang 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 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 1643 reconstructed video display problem for UpscaledOutput=1 when enable RPR VTM defect new 2024-09-06T10:16:37+02:00 2024-09-06T10:16:37+02:00 "When RPR is enabled and the video resolution is not a multiple of 8, there will be problems in the display of the decoded video(or reconstructed yuv on encoder side). Because the SPS conformance window size is not the same with the PPS conformance window size. For example: {{{ ../bin/EncoderAppStatic -c ../cfg/encoder_lowdelay_P_vtm.cfg -i input.yuv -wdt 362 -hgt 640 -f 40 --FrameRate=15 --InternalBitDepth=8 --RPR=1 --ScalingRatioHor=2.0 --ScalingRatioVer=2.0 -v 6 -q 45 -b out_vtm.bin --UpscaledOutput=1 -o rec.yuv }}} " zhijiehuang 1654 Typo in derivation process for GPM motion vectors spec defect new 2025-12-12T02:56:36+01:00 2025-12-12T02:56:36+01:00 "In section 8.5.4.2, there is a typo in step 7. The current text is 7. Let refIdxL0N and refIdxL1N, predFlagL0N and predFlagL1N, and mvL0N and mvL1N be the reference indices, the prediction list utilization flags and the motion vectors of the merging candidate N at position m in the merging candidate list mergeCandList ( N = mergeCandList[ n ] ). While the derivation within the brackets is correct, the description incorrectly says ""position m"". This should be corrected to 7. Let refIdxL0N and refIdxL1N, predFlagL0N and predFlagL1N, and mvL0N and mvL1N be the reference indices, the prediction list utilization flags and the motion vectors of the merging candidate N at position n in the merging candidate list mergeCandList ( N = mergeCandList[ n ] )." jonathang