__group__ ticket summary component version type owner status created _changetime _description _reporter v5 (02/2018) 1521 qp clip in deblock HM v5 (02/2018) defect new 2024-03-27T02:24:16+01:00 2024-03-27T02:24:16+01:00 " The qp is not cliped, using for TC and beta lookup tables when performing deblocking filtering on chroma in HM reference software,such as HM18.0 version,which is inconsistent with the protocol description. code in HM18.0： iQP = ((iQP_P + iQP_Q + 1) >> 1) + chromaQPOffset; if (iQP >= chromaQPMappingTableSize) { if (pcPicYuvRec->getChromaFormat()==CHROMA_420) { iQP -=6; } else if (iQP>51) { iQP=51; } } else if (iQP >= 0 ) { iQP = getScaledChromaQP(iQP, pcPicYuvRec->getChromaFormat()); } qp clip in SPEC： – The variables qPCb and qPCr are derived as follows: – If tu_residual_act_flag[ xTbY ][ yTbY ] is equal to 0, the following applies: qPiCb = Clip3( −QpBdOffsetC, 57, QpY + pps_cb_qp_offset + slice_cb_qp_offset + CuQpOffsetCb ) (8-287) qPiCr = Clip3( −QpBdOffsetC, 57, QpY + pps_cr_qp_offset + slice_cr_qp_offset + CuQpOffsetCr ) (8-288) – Otherwise (tu_residual_act_flag[ xTbY ][ yTbY ] is equal to 1), the following applies: qPiCb = Clip3( −QpBdOffsetC, 57, QpY + PpsActQpOffsetCb + slice_act_cb_qp_offset + CuQpOffsetCb ) (8-289) qPiCr = Clip3( −QpBdOffsetC, 57, QpY + PpsActQpOffsetCr + slice_act_cr_qp_offset + CuQpOffsetCr ) (8-290)" huxiangbin RExt-7.2 (HM-14.0) 1307 Sizes of m_ltRefPicPocLsbSps and m_usedByCurrPicLtSPSFlag are incorrect HM RExt-7.2 (HM-14.0) defect closed 2014-08-04T15:57:48+02:00 2014-08-12T11:23:32+02:00 "In HM-15.0, TComSlice.h contains these two definitions: UInt m_ltRefPicPocLsbSps![33]; Bool m_usedByCurrPicLtSPSFlag![33]; In HM-15.0+RExt-8.0, they are incorrectly defined as: UInt m_ltRefPicPocLsbSps[MAX_NUM_SPS + 1]; Bool m_usedByCurrPicLtSPSFlag[MAX_NUM_SPS + 1]; From the spec it looks as though these arrays can be as large as num_long_term_ref_pics_sps, so the correct size for these arrays would be 32? There are also a few incorrect asserts relating to these definitions. " jackh RExt-7.2 (HM-14.0) 1313 intra_smoothing_disabled_flag use in the decoder HM RExt-7.2 (HM-14.0) defect closed 2014-08-20T06:50:26+02:00 2015-02-02T17:44:00+01:00 As per standard, for Main 4:2:2 10 profile, the intra_smoothing_disabled_flag (in SPS extension) should be 0 (table A-1 of Q1005_v4_FREXT). But the HM decoder is decoding Main 4:2:2 10 profile stream with intra_smoothing_disabled_flag set as 1, without throwing any error (bitstream source: http://wftp3.itu.int/av-arch/jctvc-site/bitstream_exchange/RExt/ Main_422_10_A_RExt_Sony_1.zip). nithya HM-9.2 1049 TEncCu problems HM HM-9.2 defect closed 2013-03-21T12:42:07+01:00 2013-03-21T14:15:01+01:00 "I have add two std::queue to TEncCu.h ，they are ""queue rpcqueueSubBestPartCU and queue rpcqueueSubTempPartCU"".I just want to add pcSubBestPartCU and pcSubTempPartCU to them in TEncCu.cpp ,but when the codes execute ""rpcqueueSubBestPartCU.push(pcSubBestPartCU); rpcqueueSubTempPartCU.push(pcSubTempPartCU);"" ,there some problems occured.the problem is ""TAppEncoder.exe 中的 0x004ffef7 处未处理的异常: 0xC0000005: 写入位置 0x006f0f24 时发生访问冲突"" ,which occured in function ""inline void __CLR_OR_THIS_CALL _Container_base_secure::_Orphan_all() const""." shakingWaves HM-9.2 1011 byte_alignment() was not implemented after decoding of end_of_sub_stream_one_hot HM HM-9.2 defect closed 2013-02-18T14:05:50+01:00 2013-02-20T10:56:35+01:00 "The spec (L10003) requires that byte_alignment() is called once end_of_sub_stream_one_bit is decoded. byte_alignment() reads the next bit and it must be 1. Then, it reads the following bits until byte-alignment and they must be zero. It seems that byte_alignment() was not implemented (or was not implemented correctly) in the reference software. If my understanding is correct, these calls are written in Void TDecSbac::updateContextTables( SliceType eSliceType, Int iQp ) { m_pcTDecBinIf->decodeBinTrm(uiBit); m_pcTDecBinIf->finish(); m_pcBitstream->readOutTrailingBits(); .... m_pcTDecBinIf->decodeBinTrm(uiBit) is used to decode end_of_sub_stream_one_bit m_pcTDecBinIf->finish() is void m_pcBitstream->readOutTrailingBits() reads only bits until byte-alignment, which is not exactly byte_alignment() does. The same thing should be done for the encoder." PhuongNguyen HM-9.2 972 "The difference of motion vector out of valid range of ""short integer"" type" HM HM-9.2 defect closed 2013-01-23T08:33:30+01:00 2013-01-24T10:37:15+01:00 "In the following code to calculate boundary strength for deblocking process (in TComLoopFilter.cpp, xGetBoundaryStrengthSingle function) pcMvP0 -= pcMvQ0; pcMvP1 -= pcMvQ1; uiBs = (pcMvP0.getAbsHor() >= 4) | (pcMvP0.getAbsVer() >= 4) | (pcMvP1.getAbsHor() >= 4) | (pcMvP1.getAbsVer() >= 4); The horizontal and vertical component of motion vector was stored as ""short integer"" type in class TComMv, this will cause problem in the extreme case if the absolute difference between the horizontal or vertical component of motion vectors is greater than 32767 (the maximum value of ""short integer"" type) " jeunder HM-9.2 973 Replace HE10 for Main10 HM HM-9.2 defect closed 2013-01-23T13:06:09+01:00 2013-01-24T10:42:36+01:00 After the creation of the Main 10 profile, we may want to modify the HE10 to reflect this change. albertoduenas HM-9.2 974 Inferred value of slice_temporal_mvp_enable_flag HM HM-9.2 defect closed 2013-01-24T00:21:46+01:00 2013-01-24T10:47:28+01:00 "The HEVC specification says: ""When not present, the value of slice_temporal_mvp_enable_flag is inferred to be equal to 0."" but that is not performed in HM causing the decoder to crash when TMVP is off. The attached patch fixes the problem." jonatan HM-9.2 976 Crash on BLA with RASL HM HM-9.2 defect closed 2013-01-24T11:07:05+01:00 2013-01-24T11:13:23+01:00 "The decoder crashes when RASL pictures are associated with a BLA_W_LP picture. Moving isSkipPictureForBLA() earlier in xDecodeSlice (as in the attached patch) seems to fix the problem." jonatan HM-9.2 981 Default display window parameters used when VUI parameters not present HM HM-9.2 defect closed 2013-01-30T01:03:59+01:00 2013-01-30T17:19:47+01:00 "If VUI parameters are not present, the decoder incorrectly attempts to use the default display window parameters from the non-existent VUI. The attached patch can be used to fix the problem." bheng HM-9.2 984 Conformance top-left offset into output picture always 0 HM HM-9.2 defect closed 2013-01-31T10:43:50+01:00 2013-01-31T11:18:21+01:00 "In TLibVideoIO lines 465,479, planeOffset forced to 0, no matter what the conformance top and left positions are. The commented code on those lines appears to be correct. (Identified during RExt development.) " karlsharman HM-9.2 986 encodeQtCbfZero called with inconsistent depths HM HM-9.2 defect closed 2013-01-31T10:51:42+01:00 2013-08-13T14:29:05+02:00 "encodeQtCbfZero is called with inconsistent depths. i.e. TEncSearch.cpp lines 4925,4998, uiTrMode is used for the chroma channel, but on lines 4950,5023, uiTrModeC is used for the chroma channel. Shouldn't uiTrMode always be used, to be consistent with usage of encodeQtCbf? (Identified during RExt development.) " karlsharman HM-9.2 989 getDistPart used incorrectly for inter chroma HM HM-9.2 defect closed 2013-01-31T11:07:46+01:00 2013-01-31T14:00:08+01:00 "getDistPart has, as of HM9.2, had an extra TEXT_TYPE parameter added for chroma weighting control. A default is specified, which causes problems when not overridden: On lines 4890, 4910, 4965, 4984, 5213, 5257 of TEncSearch.cpp, TEXT_CHROMA_U or TEXT_CHROMA_V should be passed, otherwise only the Cr weighting parameter will be used. In addition, is the bWeighted flag still required, since this can be derived from the TextType passed in? (i.e. just checking that eText is not TEXT_LUMA) (Identified during RExt development.) " karlsharman HM-9.2 990 RDOQ_CHROMA_LAMBDA interaction with TComTrQuant HM HM-9.2 defect closed 2013-01-31T11:19:05+01:00 2013-09-04T13:33:13+02:00 "When RDOQ_CHROMA_LAMBDA macro is enabled, the chroma channels may have a different lambda weighting from the luma during RDOQ. However, in TEncSlice.cpp, lines 353, 470, 574, 685, 741, the calls to setLambda use the lambda for Luminance and the lambda for Cr. This will cause reduced performance when Cr's QP offset is different from Cb's QP offset. Should setLambda therefore take 3 lambda values - Y, Cb and Cr, and calls to selectLambda in TEncSearch pass in TEXT_CHROMA_U and TEXT_CHROMA_V instead of TEXT_CHROMA? There's a similar issue with SAO, but the changes required are less trivial. (Identified during RExt development.) " karlsharman HM-9.2 998 encoder: invalid sps_temporal_id_nesting_flag HM HM-9.2 defect closed 2013-02-02T12:46:41+01:00 2013-02-02T15:58:15+01:00 "When sps_max_sub_layers_minus1 is equal to 0, sps_temporal_id_nesting_flag shall be equal to 1. In HM-10.0rc1: {{{ diff --git a/source/Lib/TLibEncoder/TEncTop.cpp b/source/Lib/TLibEncoder/TEncTop.cpp index 207898c..c7ecbfd 100644 --- a/source/Lib/TLibEncoder/TEncTop.cpp +++ b/source/Lib/TLibEncoder/TEncTop.cpp @@ -524,7 +524,7 @@ Void TEncTop::xInitSPS() m_cSPS.setUseSAO( m_bUseSAO ); m_cSPS.setMaxTLayers( m_maxTempLayer ); - m_cSPS.setTemporalIdNestingFlag( false ); + m_cSPS.setTemporalIdNestingFlag( true ); for ( i = 0; i < m_cSPS.getMaxTLayers(); i++ ) { m_cSPS.setMaxDecPicBuffering(m_maxDecPicBuffering[i], i); }}} " stefane HM-9.2 1007 Invalid weighted prediction offsets HM HM-9.2 defect closed 2013-02-13T19:55:44+01:00 2013-02-19T21:38:15+01:00 "The HM-10.0 encoder can generate luma weighted prediction offset values that are outside the valid range of [-128,127]. The attached patch can be used to fix this issue. This patch also adds range checking on the decode side to detect similar issues in the future." bheng HM-9.2 1024 QP prediction may be not aligned with the spec when diff_cu_qp_delta_depth > 0 HM HM-9.2 defect closed 2013-02-27T15:49:52+01:00 2013-03-12T16:11:38+01:00 "In HM-10.0 when there are multiple CU in quantization group and only the last CU has nonzero coefficients, all the CUs of the quantization group are initialized with sliceQp and only the last CU gets QP decoded as specified in the spec. If this is the case for the 1st quantization group in the CTU, then for prediction of the QP in the second quantization group the value of sliceQp will be used as left predictor qP_Y_A and not the QP value decoded for the previous quantization group. The JCTVC_L1003_v23 clause 8.6.1 says ""The luma size of a quantization group, Log2MinCuQpDeltaSize, determines the luma size of the smallest area inside a coding tree block that shares the same qPY_PRED"" that means, to my understanding, that the QP value decoded with the last CU of the quantization group in the example above should be applied to all the CUs of the quantization group for QP prediction purposes." adolgoborodov HM-9.2 1027 RDOQ sign bit hiding HM HM-9.2 defect closed 2013-02-28T16:23:40+01:00 2013-04-20T05:03:28+02:00 "In RDOQ, on line 1988 of TComTrQuant.cpp, {{{ if(piQCoef[minPos] == 32767 || piQCoef[minPos] == -32768) }}} In this function (unlike in signBitHidingHDQ), piQCoef is the quantisation coefficients, rather than the quantised output array. It should read: {{{ if(piDstCoeff[minPos] == 32767 || piDstCoeff[minPos] == -32768) }}} " karlsharman HM-9.2 1066 How to define tiles with wavefront HM HM-9.2 defect closed 2013-04-05T14:36:35+02:00 2013-04-10T14:17:05+02:00 "hello, I am learning about the parallel capabilities of HEVC, and i would like to know how to use tiles and wavefront. i want to to reduce hevc H.M-9.2 complexity using the parallel capabillities. what should i define in the cfg file to achieve that? i am coding only 1 frame, therefor i am using only intra prediction. is there also another ways to reduce HEVC complexity ?" Moshe_M HM-9.2 17 MS VS2010 Solution HM HM-9.2 enhancement ksuehring closed 2010-07-30T16:52:25+02:00 2013-01-21T19:54:39+01:00 Could you add a visual studio 2010 solution and projects to TMuC? tn HM-9.2 987 SAO mixing quadtree indices and components HM HM-9.2 enhancement closed 2013-01-31T10:57:36+01:00 2013-11-14T20:14:47+01:00 "When rdoSaoOnePart calls TEncSampleAdaptiveOffset::estSaoTypeDist (line 194), an index is passed, but a component (Y/Cb/Cr) is expected. Is the quadtree functionality required in HM since only LCU optimisation is permitted? (Identified during RExt development.) " karlsharman HM-9.2 988 SAO_SKIP_RIGHT macro not always used HM HM-9.2 enhancement closed 2013-01-31T11:01:06+01:00 2013-01-31T14:27:27+01:00 "In TEncSampleAdaptiveOffset.cpp:calcSaoStatsCuOrg, lines 1058, 1106, 1142, 1189, 1241, SAO_SKIP_RIGHT macro is not used to guard against use of numSkipLineRight. There's also a possible inconsistency with usage in calcSaoStatsCu_BeforeDblk, where numSkipLineRight is always used, independent on SAO_SKIP_RIGHT. Is SAO_SKIP_RIGHT macro still required? (Identified during RExt development.) " karlsharman HM-9.2 991 Unnecessary array dimension of m_aapbEdgeFilter HM HM-9.2 enhancement closed 2013-01-31T11:22:53+01:00 2013-01-31T12:38:24+01:00 "TComLoopFilter::m_aapbEdgeFilter has an unnecessary array dimension: all 3 components/planes are assigned the same value, and only the 0'th element is read. (Identified during RExt development.) " karlsharman HM-9.2 992 MAX_CU_SIZE (update for HM9.2 of ticket 227) HM HM-9.2 enhancement closed 2013-01-31T11:28:27+01:00 2013-07-24T19:01:27+02:00 "MAX_CU_SIZE should be set to 6 in TComRom.h:53 If this is changed, then TComPrediction.cpp:xPredIntraPlanar:693 must be corrected: Int leftColumn[MAX_CU_SIZE], topRow[MAX_CU_SIZE], bottomRow[MAX_CU_SIZE], rightColumn[MAX_CU_SIZE]; to Int leftColumn[MAX_CU_SIZE+1], topRow[MAX_CU_SIZE+1], bottomRow[MAX_CU_SIZE], rightColumn[MAX_CU_SIZE]; -- In addition, the definition of g_aucIntraModeNumFast[7] should be g_aucIntraModeNumFast[MAX_CU_DEPTH] in TComRom.h:133 and TComRom.cpp:278 and 289 (and if MAX_CU_DEPTH is set to 6, the last element should be removed from their definition). (Identified during RExt development.) " karlsharman HM-9.2 995 Removal of variable bPreviousPictureDecoded HM HM-9.2 enhancement closed 2013-01-31T23:28:39+01:00 2013-07-24T16:27:41+02:00 The variable bPreviousPictureDecoded in TAppDecTop.cpp is effectively not used for any purpose. The attached patch removes the variable and its occurrences. adarsh HM-9.2 1026 TComTrQuant::xGetICRate is deprecated. HM HM-9.2 enhancement closed 2013-02-28T10:50:37+01:00 2013-08-13T14:14:22+02:00 "The three references to xGetICRate in RDOQ should be changed to xGetICRateCost (all parameters are the same). xGetICRate uses the old scheme of Golomb-Rice coding but appears to function similarly to xGetICRateCost that uses the updated scheme. (xGetICRateCost also accounts for cost of sign bit, but this will not cause a problem where xGetICRate is concerned, since those places consider relative differences.)" karlsharman HM-9.2 983 Unused variables and functions HM HM-9.2 enhancement closed 2013-01-31T10:39:13+01:00 2013-01-31T12:44:05+01:00 "g_aucIntraModeNumAng, g_aucIntraModeBitsAng, g_aucIntraModeOrder declared and not used in TComRom.h TComDataCU.cpp/h:xGetCenterCol is a redundant function. (Identified during RExt development.) " karlsharman HM-9.2 985 Reversed width/height assignments in SAO HM HM-9.2 enhancement closed 2013-01-31T10:45:45+01:00 2013-01-31T12:46:10+01:00 "In TEncSampleAdaptiveOffset.cpp, calcSaoStatsCU_BeforeDBlk line 1330, lcuWidth assigned height, lcuHeight assigned width. (Identified during RExt development.) " karlsharman HM-9.2 993 TEncSAO m_dLambdaLuma/Chroma member variables not required HM HM-9.2 enhancement closed 2013-01-31T14:40:50+01:00 2013-04-10T14:11:37+02:00 "In TEncSampleAdaptiveOffset.h:59,60, m_dLambdaLuma and m_dLambdaChroma are defined. These are written to only within TEncSampleAdaptiveOffset::SAOProcess, and never read. Suggest removal of declarations in TEncSampleAdaptiveOffset.h and remove the following lines of TEncSampleAdaptiveOffset.cpp:1706 #if SAO_CHROMA_LAMBDA m_dLambdaLuma=dLambdaLuma; m_dLambdaChroma=dLambdaChroma; #else m_dLambdaLuma=dLambda; m_dLambdaChroma=dLambda; #endif (Identified during RExt development.) " karlsharman HM-9.2 996 "Missing "".vcxproj.filters"" files" HM HM-9.2 enhancement closed 2013-02-01T02:29:56+01:00 2013-02-01T10:28:13+01:00 "In MS VS2010, rules for the tree view in Solution Explorer are provided separately in "".vcxproj.filters"" files, unlike they are included in "".vcproj"" files in earlier versions. It would be nicer to add "".vcxproj.filters"" files into the repository. Attached are "".vxproj.filters"" files created by MS VS2010 automatically when upgrading VS2008 projects to VS2010 projects." hao HM-9.1 940 When strong_intra_smoothing_enable_flag=1, wrong neighboring samples are used. HM HM-9.1 defect closed 2013-01-09T11:15:06+01:00 2013-01-19T16:44:36+01:00 "In near-the-end of function initAdiPattern(), the result (of applying strong-intra-smoothing or not) is filled into ''piFilteredBuf1''. In function predIntraLumaAng(): if ( (iWidth > 16) | | (iHeight > 16) ) { xPredIntraAng(g_bitDepthY, ptrSrc+sw+1, sw, pDst, uiStride, iWidth, iHeight, uiDirMode, bAbove, bLeft, false ); } ptrSrc+sw+1 should be ptrSrc+65*65+sw+1 (that means ''piFilteredBuf1''+sw+1), for example, when the CTB size is 64x64. Otherwise, the neighboring samples used are still NOT strong-intra-smoothed, even when the condition is met (biIntFlag=1, see the spec)." conrad.ho HM-9.1 994 Emulation prevention bytes igonred by HM decoder to calculate entry_point_offset[ i ] when entropy_coding_sync_enabled_flag is enabled. HM HM-9.1 defect closed 2013-01-31T16:27:42+01:00 2013-03-15T17:04:07+01:00 "The section 7.9.4.1 of standard says that emulation prevention bytes are included to calculate entry_point_offset[i] where i = 0 to num_entry_point_offsets, when entropy_coding_sync_enabled_flag is equal to 1. However it seems like HM 9.1 decoder is reading the substream in TComInputBitstream::extractSubstream() (after having removed the emualtion prevention bytes). This means there implementation assumes that entry point offset does not include the number of emulation prevention bytes. As a result decoder starts decoding a row at wrong offset." chethan879 HM-9.1 804 SEI payload type mismatch HM HM-9.1 defect closed 2012-10-21T07:48:33+02:00 2013-01-08T16:32:18+01:00 "The mismatch occurs for the ""decoded picture hash"" SEI message. WD (K0030): else if( payloadType = = 130) decoded_picture_hash( payloadSize ) HM 8.1: DECODED_PICTURE_HASH = 256, It is suggested to fix the software by aligning it to the text: DECODED_PICTURE_HASH = 130, " fbossen HM-9.1 888 VUI pic_struct_present_flag is used without initialization. HM HM-9.1 defect closed 2012-12-05T01:49:43+01:00 2012-12-05T20:27:17+01:00 "The value of m_picStructPresentFlag is not initialized before encoding causing the encoder to corrupt other fields in the bitstream. It is also not possible to initialize this variable from the encoder config file. The attached patch can be used to fix this issue." bheng HM-9.1 889 Copy colour primaries value from TEncTop to TComVUI HM HM-9.1 defect closed 2012-12-06T04:04:19+01:00 2012-12-07T18:59:41+01:00 "In TEncTop.cpp, the value of colour primaries is not copied from the m_pcTEncTop object to pcVUI object, along with the initialization of other VUI parameters. Left as such, the value assigned to colour primaries in the configuration file will not neither used nor signaled by the encoder; the default value would be chosen. Attached patch is one solution to this. " adarsh HM-9.1 892 QP inheritance problem at bottom of non-CTU-multiple height images HM HM-9.1 defect closed 2012-12-07T14:18:25+01:00 2013-01-08T22:26:12+01:00 " Using a variable QP, a CTU size of 64 and class D images (ie, the bottom CTU row does not fully intersect the image being coded), there is a QP inheritance problem on the last row if a dependent slice starts later than the left-most CTU. There is a decoder mismatch during decoding, as a wrong QP may be used. This is due to the fact that the data in CTUs corresponding to an area outside of the image are not correctly initialized in the decoder when a slice (dependent or independent) is terminated. These data are later used, however, when searching for a 'last QP coded' from a dependent-slice CTU directly to the right. The attached patch prevents a 'break' occuring during traversal of the CTU when 'isLast' is seen, and correctly completes CTU initialisation when 'isLast' is true. Possibly related to ticket #671, but this issue was not seen with HM 9.0. " gordon HM-9.1 901 Don't change Lambda for I slices when HadamardME is disabled HM HM-9.1 defect closed 2012-12-11T14:43:58+01:00 2012-12-12T13:41:31+01:00 When HadamardME is set to zero, the lambda value is changed for all slice types. Changing the ME options should not have influence on intra only coding. Thus we suggest to change the value only for non-I slices. ksuehring HM-9.1 913 Wrong pointer to SPS HM HM-9.1 defect closed 2012-12-15T02:16:58+01:00 2013-01-19T17:23:16+01:00 "While parsing SEI messages, the SPS parameters to be updated are updated using m_SEIs->m_pSPS that is initialized as ''m_SEIs->m_pSPS = m_parameterSetManagerDecoder.getSPS(0);'' The allocation should rather be ''m_SEIs->m_pSPS = m_parameterSetManagerDecoder.getPrefetchedSPS(0);'' because only that fetches the SPS from the correct buffer. Now, the use of ""0"" as the ID for the SPS to be accessed is another error (works only as long as the only SPS id used is 0), but that fix would need much more work." adarsh HM-9.1 919 Chroma QP offsets not use in forward quantization HM HM-9.1 defect closed 2012-12-18T02:01:01+01:00 2012-12-18T02:31:03+01:00 "When RDOQ is off, the forward quantization does not use chroma QP offsets. Dequantization correctly uses the Chroma QP offsets during reconstruction. The encoder and decoder are matched but the quantization process may introduce unintended error. For example reducing QP by using a value of -12 for CrQpOffset should increase the V psnr but the psnr is lowered compared to CrQpOffset of zero. A patch is attached." lkerofsky HM-9.1 920 Missing pocCRA update causes decoder assertion failure HM HM-9.1 defect closed 2012-12-18T16:06:16+01:00 2013-01-09T04:51:37+01:00 While testing HM-9.1 we discovered that the HM decoder encounters an assertion failure at line 600 in the TComSlice.cpp. The bitstream is valid however currently the value of variable pocCRA is not updated at the decoder when an IDR NALU type is encountered in the bitstream. The attached fix proposes a change that updates pocCRA when an IDR or IDR_N_LP NALU type is encountered. kiranmisra HM-9.1 922 RDOQ missing support for chroma QP offsets HM HM-9.1 defect closed 2012-12-18T18:47:23+01:00 2012-12-18T23:17:31+01:00 The chroma distortion weighting in RDOQ does not account for chroma QP offsets. A patch is attached which uses separate weights for Cb and Cr, computes the weights using appropriate QP offsets, includes the chroma format in RDOQ function calls to select the appropriate weight. lkerofsky HM-9.1 923 SAO Skip Right HM HM-9.1 defect weipu closed 2012-12-20T20:49:12+01:00 2014-01-11T21:26:33+01:00 "In TEncSampleAdaptiveOfft.cpp:1031 It should be: Int numSkipLineRight = iIsChroma? 2:4; Because in current version of Deblocking Filter, maximum of 4 pixels are read and maximum of 3 pixels can be modified for both horizontal and vertical direction." weipu HM-9.1 925 bug in derivation of temporal motion vectors for merge mode HM HM-9.1 defect closed 2012-12-21T11:38:56+01:00 2013-01-19T16:16:58+01:00 "According to the spec, section 8.5.3.1.1 Derivation process for luma motion vectors for merge mode: 3. The derivation process for temporal luma motion vector prediction in subclause 8.5.3.1.7 is invoked with luma location ( xP, yP ), the width and the height of the luma prediction block nPbW and nPbH, and refIdxLXCol as the inputs and the output being the availability flags availableFlagLXCol and the temporal motion vectors mvLXCol (with X being 0 or 1, respectively). The variables availableFlagCol and predFlagLXCol (with X being 0 or 1, respectively) are derived as specified below. , 8.5.3.1.7 is invoked independently and unconditionally for both L0 and L1. But in TComDataCU::getInterMergeCandidates(), 8.5.3.1.7 is only invoked for L1 if availableFlagL0Col is true: {{{ bExistMV = uiLCUIdx >= 0 && xGetColMVP( REF_PIC_LIST_0, uiLCUIdx, uiAbsPartAddr, cColMv, iRefIdx ); if( bExistMV == false ) { bExistMV = xGetColMVP( REF_PIC_LIST_0, uiCurLCUIdx, uiPartIdxCenter, cColMv, iRefIdx ); } if( bExistMV ) // <- only if availableFlagL0Col is true { // ... if ( getSlice()->isInterB() ) { iRefIdx = 0; bExistMV = uiLCUIdx >= 0 && xGetColMVP( REF_PIC_LIST_1, uiLCUIdx, uiAbsPartAddr, cColMv, iRefIdx); }}} The inter prediction mode for temporal merge mode motion vectors can therefore only be Pred_L0 or Pred_BI but never Pred_L1. " stefane HM-9.1 928 Wrong picture marking information usage in derivation of motion vector components HM HM-9.1 defect closed 2012-12-24T19:26:10+01:00 2013-01-10T18:56:54+01:00 "In HM during the motion information derivation process, wrong picture marking information is for collocated partition's reference frame. HM uses collocated partition's current picture marking information (short term or long term) instead of its picture marking information at the time of its usage as a reference frame as specified in section 8.5.3.1 of the latest specification draft. The issue shows up when TMVP is enabled with long term reference pictures. Attached patch addresses this problem. In High Efficiency Video Coding (HEVC) text specification draft 9 section 8.5.3.1 8.5.3.1 Derivation process for motion vector components and reference indices ... The function LongTermRefPic( nPic, nPb, refIdx, LX ), with X being either 0 or 1, is defined as follows. If the picture with index refIdx from reference picture list LX of the slice containing prediction block nPb in the picture nPic was marked as ""used for long term reference"" at the time when nPic was the current picture, LongTermRefPic( nPic, nPb, refIdx, LX ) is equal to 1; otherwise LongTermRefPic( nPic, nPb, refIdx, LX ) is equal to 0. ..." mcoban HM-9.1 929 Deblocking filter boundary strength derivation bug (encoder) HM HM-9.1 defect closed 2012-12-24T20:06:27+01:00 2013-02-04T12:03:28+01:00 "Unitialized motion vector information is used during the boundary strength derivation on the encoder side leading to encoder/decoder mismatches. The xGetBoundaryStrengthSingle() function assumes the motion vectors of refIdx < 0 blocks have the value 0. e.g. {{{ xGetBoundaryStrengthSingle() ..... if ( ((piRefP0==piRefQ0)&&(piRefP1==piRefQ1)) || ((piRefP0==piRefQ1)&&(piRefP1==piRefQ0)) ) { uiBs = 0; if ( piRefP0 != piRefP1 ) // Different L0 & L1 { if ( piRefP0 == piRefQ0 ) { pcMvP0 -= pcMvQ0; pcMvP1 -= pcMvQ1; uiBs = (pcMvP0.getAbsHor() >= 4) | (pcMvP0.getAbsVer() >= 4) | (pcMvP1.getAbsHor() >= 4) | (pcMvP1.getAbsVer() >= 4); ..... }}} If piRefP1==piRefQ1==NULL and piRefP0 == piRefQ0 && piRefP0 != NULL, motion vector information of P1 partition is used in uiBs derivation. following patch should address the issue" mcoban HM-9.1 931 incorrect parsing of lt_idx_sps if num_long_term_ref_pics_sps == 1 HM HM-9.1 defect closed 2012-12-25T10:12:43+01:00 2013-01-07T17:47:57+01:00 "According to the spec, if num_long_term_ref_pics_sps == 1, parsing lt_idx_sps should consume Ceil( Log2( 1 ) ) = 0 bits. In HM, lt_idx_sps consumes 1 bit if num_long_term_ref_pics_sps == 1. {{{ Int bitsForLtrpInSPS = 1; while (rpcSlice->getSPS()->getNumLongTermRefPicSPS() > (1 << bitsForLtrpInSPS)) { bitsForLtrpInSPS++; } }}} Parsing of lt_idx_sps should probably use code equivalent to that for parsing short_term_ref_pic_set_idx." stefane HM-9.1 934 g_auiRasterToZscan Address Calculation out of range in TComPattern::initPattern HM HM-9.1 defect closed 2013-01-03T02:05:43+01:00 2013-01-04T20:21:56+01:00 "In TComPattern::initPattern function, if( uiCurrPicPelY != 0 ) { UInt uiNumPartInWidth = ( uiWidth/pcPic->getMinCUWidth() ); uiOffsetAbove = 1; if( uiCurrPicPelX + uiWidth < pcCU->getSlice()->getSPS()->getPicWidthInLumaSamples() ) { if( ( g_auiZscanToRaster[uiAbsZorderIdx] + uiNumPartInWidth ) % pcPic->getNumPartInWidth() ) // Not CU boundary { if( g_auiRasterToZscan[ (Int)g_auiZscanToRaster[uiAbsZorderIdx] - (Int)pcPic->getNumPartInWidth() + (Int)uiNumPartInWidth ] < uiAbsZorderIdx ) { uiOffsetRight = 1; } } ... The g_auiRasterToZscan[ (Int)g_auiZscanToRaster[uiAbsZorderIdx] - (Int)pcPic->getNumPartInWidth() + (Int)uiNumPartInWidth ] may have out of range problem, due to the calculation of (Int)g_auiZscanToRaster[uiAbsZorderIdx] - (Int)pcPic->getNumPartInWidth() + (Int)uiNumPartInWidth may be < 0. This will cause the visiting address of g_auiRasterToZscan[] is out of range and random value is obtained. It should be changed as follows: if( uiCurrPicPelY != 0 ) { UInt uiNumPartInWidth = ( uiWidth/pcPic->getMinCUWidth() ); uiOffsetAbove = 1; if( uiCurrPicPelX + uiWidth < pcCU->getSlice()->getSPS()->getPicWidthInLumaSamples() ) { if( ( g_auiZscanToRaster[uiAbsZorderIdx] + uiNumPartInWidth ) % pcPic->getNumPartInWidth() ) // Not CU boundary { if ((Int)g_auiZscanToRaster[uiAbsZorderIdx] - (Int)pcPic->getNumPartInWidth() + (Int)uiNumPartInWidth >= 0 ) { if( g_auiRasterToZscan[ (Int)g_auiZscanToRaster[uiAbsZorderIdx] - (Int)pcPic->getNumPartInWidth() + (Int)uiNumPartInWidth ] < uiAbsZorderIdx ) { uiOffsetRight = 1; } } } ... " yul HM-9.1 942 HM 9.1 entry_point_offset issue HM HM-9.1 defect closed 2013-01-09T14:47:15+01:00 2013-01-28T10:39:14+01:00 "I was trying to independently decode tiles using HM 9.1. I made three streams: ""stream 1"": all intra ""stream 2"": random access ""stream 3"": lowdelay In order to make the tiles independently decodable I used the following settings: {{{ --SAO=0 --UniformSpacingIdc=1 --NumTileColumnsMinus1=1 --NumTileRowsMinus1=1 --LFCrossTileBoundaryFlag=0 }}} Within the software it is possible to fake a parallel decoding process inside the function ''TDecSlice::decompressSlice''. I made accessible the values of ''m_fifo_idx'' (decleared in ''TComBitStream.h'') and ''entry_point_offset''. In particular I wrote: {{{ Void setEntryPointOffsets(Int num, UInt *val) { m_entryPointOffsets = new UInt[num + 1]; m_entryPointOffsets[0] = 0; for(int i = 1; i < num + 1; i++) m_entryPointOffsets[i] = val[i-1]; } UInt getEntryPointOffset(Int num) { UInt val = 0; for (int i = 0; i < num+1; i++) val += m_entryPointOffsets[i]; return val; } }}} Everything works fine with ""stream 1"" if the resolution is 1920x1080 or 3840x2160. Everything is ok also for ""stream 2"" and ""stream 3"" but only when resolution is 1920x1080. When I encode a video at UHD1 resolution, with ""stream 2"" I see that, for the first frame ''m_fifo_idx'' is equal to ''getEntryPointOffset minus 1'', while the following frames have ''m_fifo_idx'' equal to ''getEntryPointOffset''. With ""stream 3"" the first frame is decoded with ''m_fifo_idx'' equal to ''getEntryPointOffset'' while, for the following frames the decoding of some tiles start with ''m_fifo_idx'' equal to ''getEntryPointOffset minus 1'' and other with ''m_fifo_idx'' equal to ''getEntryPointOffset''." ike HM-9.1 943 1-CTB wide picture, wavefront, and dependent slices HM HM-9.1 defect closed 2013-01-09T20:09:13+01:00 2013-01-11T15:12:12+01:00 "In the special case of a 1-CTB wide picture, the top-right CTB is never available for wavefront synchronization, so the CABAC context at the start of every CTB row should be reinitialized to the default values. However, if the first CTB in a row is also the first CTB in a dependent slice, HM will continue using the CABAC context from the previous row. " bheng HM-9.1 946 32-bit Dequantization Overflow when QP=47 HM HM-9.1 defect closed 2013-01-10T22:50:27+01:00 2013-01-11T01:44:48+01:00 " The non-normative clipping described in H0541, and implemented in HM, attempts to avoid 32-bit overflow of intermediate results by clipping coefficients to a 15-bit range prior to dequantization for 4x4 blocks when scaling lists are used and QP>=48. However, the intermediate results can still overflow when QP=47. For example, using the largest weight and coefficient level: (L * IQ * W) << (QP/6 - iShift) = (-32768 * 72 * 255) << 2 = -2406481920 (33 bit signed value) In HM, the resulting dequantized coefficients overflow the 32 bit integers used to store these results. I believe the attached patch would fix the problem. " bheng HM-9.1 947 Intializing DU removal time for picture timing SEI message HM HM-9.1 defect closed 2013-01-10T23:46:58+01:00 2013-01-19T13:11:58+01:00 "When HM-9.1-dev (after r3199) is run with VUI parameters on and signalling picture timing SEI message, some of the DU removal increments are set negative value. The errors occurs duee to the code at line 1521 in TEncGop.cpp (below). if( (Int)pCRD[ i ] < 0 ) { pCRD[ i ] ++; } The lines should be if( (Int)pCRD[ i ] < 0 ) { pCRD[ i ] = 0; } The reason is that the value of variable pCRD[i] derived before this line could be -2 or lower based on the difference between the values of removal time of that DU (calculated based on the number of bits) and succeeding DUs in decoding order (calculated based on the pCRD values; pCRD values are non-negative). " adarsh HM-9.1 949 Number of NAL units in picture timing SEI for first DU HM HM-9.1 defect closed 2013-01-11T12:58:46+01:00 2013-01-19T13:12:25+01:00 "The code for the number of NAL units in the first DU for picture timing SEI message has a ""-1"" missing. The line of code (in TEncGop.cpp, HM-9.1-dev) pictureTimingSEI.m_numNalusInDuMinus1[ i ] = ( i == 0 ) ? ( accumNalsDU[ i ] ) : ( accumNalsDU[ i ] - accumNalsDU[ i - 1] - 1 ); should be pictureTimingSEI.m_numNalusInDuMinus1[ i ] = ( i == 0 ) ? ( accumNalsDU[ i ] '''- 1''' ) : ( accumNalsDU[ i ] - accumNalsDU[ i - 1] - 1 );" adarsh HM-9.1 951 missing colon in case statement in SEIwrite.cpp HM HM-9.1 defect closed 2013-01-14T23:43:58+01:00 2013-01-15T12:05:29+01:00 "There is a missing colon at the end of the following line in SEIwrite.cpp. case SEI::DECODING_UNIT_INFO " dthoang HM-9.1 953 Best motion not stored during uni-directional search in list1 in certain case HM HM-9.1 defect closed 2013-01-17T10:37:12+01:00 2014-11-18T18:19:47+01:00 "In case the same picture inserted into both list0 and list1 at the same position, the best motion from list1 search may not be stored correctly. This bug dose not show up in the current HM configuration. It is found under the context of ref_idx approach implementation in SHVC software SMuC0.1.1. Detailed description of the bug and the fix can be found in document JCTVC-L0167." hyang HM-9.1 954 VPS extension assert HM HM-9.1 defect closed 2013-01-17T10:53:37+01:00 2013-01-19T13:06:21+01:00 "The HM VPS parsing code (in TDecCAVLC.cpp) contains an assert to check that vps_extension_flag is equal to 0 and does not parse vps_extension_data_flag, but the specification requires that when vps_extension_data_flag is equal to 1 conforming decoders shall ignore all data that follow the vps_extension_flag. The attached patch (based on HM-9.1-dev rev 3218) fixes the problem with a solution that matches how sps_extension_flag is handled. " jonatan HM-9.1 965 Non-reference random-access leading pictures are not supported. HM HM-9.1 defect closed 2013-01-20T19:10:42+01:00 2013-01-22T15:01:39+01:00 "The slice types NAL_UNIT_CODED_SLICE_RADL_N NAL_UNIT_CODED_SLICE_RASL_N are defined but never used in the HM-9.2 code. I believe the attached patch would fix the issue. " bheng HM-9.1 968 Encoding and decoding mismatch r3288 HM HM-9.1 defect closed 2013-01-21T16:18:50+01:00 2013-01-21T17:38:04+01:00 "Encoding and decoding mismatch in r3288 with the following command line TAppEncoder.exe -c encoder_lowdelay_main.cfg -c RaceHorses.cfg -f 3 -q 37 --SEIpictureDigest=1" libin HM-9.1 891 [clean-ups] Merge-related codet HM HM-9.1 enhancement closed 2012-12-07T10:15:20+01:00 2014-11-18T12:27:18+01:00 "For better understanding of the merge-related code part, I suggest the following clean-ups: (1) Removal of unused arguments of decodeMergeIndex(): puhInterDirNeighbours and pcMvFieldNeighbours. (2) Change of the name of variable isMerged to hasMergeCandList for better understanding. (3) Prevention of unnecessary (i.e., has-no-effect) calls of pcSubCU->setPartSizeSubParts() both in encoder and decoder. Please check the attached patch file for details. Note that the suggested clean-ups have no effect on the encoded and decoded results. " huiyong HM-9.1 945 unused xCheckBestMode function HM HM-9.1 enhancement closed 2013-01-10T18:02:16+01:00 2013-01-10T18:32:48+01:00 "It seems that the function xCheckBestMode without depth parameter is never used in HM Code. {{{ // check whether current try is the best Void TEncCu::xCheckBestMode( TComDataCU*& rpcBestCU, TComDataCU*& rpcTempCU ) }}}" bbross HM-9.1 885 Video parameter set RBSP syntax issues HM HM-9.1 defect closed 2012-12-02T15:46:42+01:00 2012-12-17T22:50:40+01:00 "The syntax element vps_max_nuh_reserved_zero_layer_id is used but not defined. The position of the syntax element vps_temporal_id_nesting_flag in the spec differs from HM-9.1rc1. " stefane HM-9.1 962 mistake in Width/Height HM HM-9.1 defect weipu closed 2013-01-18T23:37:20+01:00 2013-01-19T13:10:19+01:00 "in TEncSampleAdaptiveOffset.cpp Line 1006, 1007 are: Int iLcuWidth = pTmpSPS->getMaxCUHeight(); Int iLcuHeight = pTmpSPS->getMaxCUWidth() The correct code should be: Int iLcuHeight = pTmpSPS->getMaxCUHeight(); Int iLcuWidth = pTmpSPS->getMaxCUWidth() " weipu HM-9.1 963 Width/Height wrong HM HM-9.1 defect weipu closed 2013-01-18T23:45:56+01:00 2013-01-19T13:09:05+01:00 "In TEncSampleAdaptiveOffset.cpp Line 1298, 1299 Int lcuWidth = pTmpSPS->getMaxCUHeight(); Int lcuHeight = pTmpSPS->getMaxCUWidth(); The correct code should be: Int lcuHeight = pTmpSPS->getMaxCUHeight(); Int lcuWidth = pTmpSPS->getMaxCUWidth()" weipu HM-9.0 869 r3089 broken system of checksum SEI HM HM-9.0 defect adarsh closed 2012-11-29T15:04:20+01:00 2012-11-29T20:38:44+01:00 "In the branch HM-9.0-dev: the code in TDecTop::xDecodeSEI -> ""m_SEIs = m_pcPic->getSEIs()"" always got pointer NULL, so the decoder crash here. and decoder can't found/verify checksum when use suffix SEI. " chenm003 HM-9.0 834 Decoder hangs @ TAppDecTop::destroy() HM HM-9.0 defect closed 2012-11-11T11:43:12+01:00 2012-11-21T17:17:27+01:00 "The decoder hangs if it runs without parameters. The trivial patch was attached. The version: trunk/rev 2993 OS: Windows 7 x 64 Compiler: MS Visual Studio 10 Professional " achuykov HM-9.0 867 Problem with SEI message reading HM HM-9.0 defect closed 2012-11-28T23:48:14+01:00 2012-11-29T00:34:15+01:00 "I am not sure if the problem is in the spec or in the HM9.0rc1 software First look at line 89 of SEIread.cpp background: An sei_rbsp can hold more than one sei_message (ref 7.3.2.4) The software keeps reading sei_messages until the next byte in the stream is equal to 0x80. However, if a sei_message whose payload type, is not the first sei_message in an sei_rbsp, then it would terminate. There is a sei_message whose payloadType = 128, and that is an sop_description (reference D.1.1) Feedback would be appreciated. --James Michener james@michener.com " michener HM-9.0 485 HM software does not cope with different values of tc / beta across slices HM HM-9.0 defect closed 2012-04-13T02:22:00+02:00 2012-11-29T22:31:58+01:00 Like AVC, HEVC can deblock accross slices, and the two slices can have different values for beta_offset_div2 and tc_offset_div2. HM will have to take care to use the value from the slice containing the pixel q0. pieterkapsenberg HM-9.0 753 Low Delay flag isn't set for P slices HM HM-9.0 defect closed 2012-09-18T19:38:09+02:00 2012-12-02T23:27:39+01:00 "In TDecTop.cpp, the flag bLowDelay is computed only for B slices, so for P slices it remains at the default false value, which is not necessarily the case. This results in incorrectly decoded motion vectors. The draft text makes no such distinction. A suggested fix is below: Before: {{{ if (pcSlice->isInterB()) { Bool bLowDelay = true; Int iCurrPOC = pcSlice->getPOC(); Int iRefIdx = 0; for (iRefIdx = 0; iRefIdx < pcSlice->getNumRefIdx(REF_PIC_LIST_0) && bLowDelay; iRefIdx++) { if ( pcSlice->getRefPic(REF_PIC_LIST_0, iRefIdx)->getPOC() > iCurrPOC ) { bLowDelay = false; } } for (iRefIdx = 0; iRefIdx < pcSlice->getNumRefIdx(REF_PIC_LIST_1) && bLowDelay; iRefIdx++) { if ( pcSlice->getRefPic(REF_PIC_LIST_1, iRefIdx)->getPOC() > iCurrPOC ) { bLowDelay = false; } } pcSlice->setCheckLDC(bLowDelay); } }}} After: {{{ Bool bLowDelay = true; Int iCurrPOC = pcSlice->getPOC(); Int iRefIdx = 0; for (iRefIdx = 0; iRefIdx < pcSlice->getNumRefIdx(REF_PIC_LIST_0) && bLowDelay; iRefIdx++) { if ( pcSlice->getRefPic(REF_PIC_LIST_0, iRefIdx)->getPOC() > iCurrPOC ) { bLowDelay = false; } } if (pcSlice->isInterB()) { for (iRefIdx = 0; iRefIdx < pcSlice->getNumRefIdx(REF_PIC_LIST_1) && bLowDelay; iRefIdx++) { if ( pcSlice->getRefPic(REF_PIC_LIST_1, iRefIdx)->getPOC() > iCurrPOC ) { bLowDelay = false; } } } pcSlice->setCheckLDC(bLowDelay); }}} " pieterkapsenberg HM-9.0 790 Leftover disable_deblocking_filter_flag value used during slice header parsing. HM HM-9.0 defect closed 2012-10-05T19:37:52+02:00 2012-11-19T19:51:53+01:00 "When deblocking filter controls were included in the previous picture and deblocking was disabled, the HM-8.1 decoder fails to reset the slice_disable_deblocking_filter_flag for the current picture when deblocking filter controls are not enabled in the current picture’s PPS. For the purpose of configuring the deblocking filter, the decoder still works correctly since this case is handled in TComLoopFilter::setCfg( ). However, re-enabling the deblocker also affects the parsing of the slice_loop_filter_across_slices_enabled_flag. The attached patch provides one way to solve this issue. " bheng HM-9.0 828 collocated_from_l0_flag is not used properly in temporal MV process HM HM-9.0 defect closed 2012-11-06T23:25:20+01:00 2012-11-29T01:22:04+01:00 "In TComDataCU.cpp, line 3542, the following correction should be made: {{{ eColRefPicList = getSlice()->getCheckLDC() ? eRefPicList : RefPicList(getSlice()->getColFromL0Flag()); }}} should be changed to: {{{ eColRefPicList = getSlice()->getCheckLDC() ? eRefPicList : RefPicList(1-(getSlice()->getColFromL0Flag())); }}}" pieterkapsenberg HM-9.0 829 Handling of unknown SEI payload types HM HM-9.0 defect closed 2012-11-07T01:49:50+01:00 2012-11-08T12:55:48+01:00 "The current decoder reports an assertion failure when the parsed SEI payload type is not in the candidate list. The suggested fix will print a message reporting this finding but continue decoding." peisongc HM-9.0 832 CRC calculation incorrect for bit depths greater than 8 HM HM-9.0 defect closed 2012-11-09T20:56:41+01:00 2012-11-19T20:07:11+01:00 "There is currently a mismatch between the SEI picture hash CRC calculation in WD9 and HM-9.0. When the bit depth is greater than 8, the WD text splits each pixel into two bytes. The CRC is then calculated on each of these bytes, 16 bits total, in the following order. {{{ MSB LSB 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 }}} HM attempts to take the CRC of only the active bits. So for 10-bit pixels it would try to process just 10 bits, with bits in the following order: {{{ MSB LSB X X X X X X 0 1 2 3 4 5 6 7 8 9 }}} In addition, there is a bug in the code used to do this. Specifically, the & operator being used below to replace a modulo operation only works for the 8-bit case. This cannot be directly extended to 10-bits, etc... {{{ (dataMsbIdx - (bitIdx&dataMsbIdx)) }}} I believe the attached patch would fix HM to match the WD text. " bheng HM-9.0 833 Chroma QP offsets cause encoder / decoder mismatch HM HM-9.0 defect closed 2012-11-11T01:19:18+01:00 2012-11-19T20:10:48+01:00 "The Chroma Cr QP is not always set during encoding depending on whether the Cb QP was already set or not. This causes encoder / decoder mismatches, particularly when the Cb and Cr offsets are not the same. I believe the attached patch would fix the problem. " bheng HM-9.0 835 Invalid SPS pointer used during picture output HM HM-9.0 defect ksuehring closed 2012-11-12T21:28:15+01:00 2012-11-22T10:53:20+01:00 "The xWriteOutput and xFlushOutput functions reference slice SPS pointers that may not be valid when the picture is actually output. Using these invalid SPS parameters (picCropping and numReorderPics) can cause the decoder to crash. The attached patch attempts to store the relevant parameters with the picture itself so the SPS pointer is not used at output time. " bheng HM-9.0 837 MaxNumMergeCand in dependent slices HM HM-9.0 defect closed 2012-11-13T03:14:22+01:00 2012-11-19T20:15:43+01:00 "The maxNumMergeCand is not currently being copied in the copySliceInfo( ) function, so it is not being set correctly for dependent slices. The attached patch fixes the issue. " bheng HM-9.0 840 Slices incorrectly encoded when wavefront is enabled HM HM-9.0 defect closed 2012-11-13T23:26:22+01:00 2012-11-28T22:58:05+01:00 "During encoding, the derivation of SliceCurEndCUAddr can be inconsistent between the compressSlice() and encodeSlice() functions when wavefront is used with slices. This causes the same CTB to be re-encoded into more than one slice. I believe the attached patch should fix the issue. " bheng HM-9.0 845 [SAO] filterPicture(), entering SAOProcess() condition flaw HM HM-9.0 defect closed 2012-11-19T08:47:07+01:00 2012-12-04T23:57:45+01:00 "The spec allows each slice with different slice_sao_luma_flag/slice_sao_chroma_flag value. However, in the function filterPicture(), it only checks the flags of the first slice to determine the whole frame needs SAO process or not. pcSlice = rpcPic->'''getSlice(0)'''; ... if( pcSlice->getSPS()->getUseSAO() ) { if(pcSlice->getSaoEnabledFlag()||pcSlice->getSaoEnabledFlagChroma()) { ... m_pcSAO->SAOProcess(rpcPic, saoParam); ... } } This contradicts the spec when multiple slices, 1st slice is without SAO, but some other slice(s) is with SAO." conrad.ho HM-9.0 861 LosslessCuEnabled flag in encoder config HM HM-9.0 defect closed 2012-11-23T14:13:51+01:00 2013-01-09T01:54:31+01:00 "Encoder config file has LosslessCuEnabled input parameter, where its corresponding explanation is: Set ""qpprime_y_zero_transquant_bypass_flag=1"" and enable the lossless mode as well as the RD-based mode selection process. However, qpprime_y_zero_transquant_bypass_flag is not present in HEVC SoDIS. " kugur HM-9.0 872 overwrite SPS parameters when different id SPS is decoded HM HM-9.0 defect closed 2012-11-30T10:46:28+01:00 2013-03-26T19:34:40+01:00 "In SPS parsing of HM9.0.1, global variables are set equal to parsing data. (e.g. g_uiMaxCUWidth, g_uiMaxCUDepth) Therefore, SPS parameters are overwritten when different id SPS is decoded." sue.naing HM-9.0 877 HM-9.1rc1 lowdelay_P cfg incorrect HM HM-9.0 defect closed 2012-12-02T05:30:10+01:00 2012-12-02T06:02:19+01:00 "B picture instead of P picture is used in lowdelay_P_main and lowdelay_P_he10 cfg, r3108. Frame1: B 1 3 0.4624 0 0 0 4 4 -1 -5 -9 -13 0" libin HM-9.0 878 Mismatch between WD-9 session 8.7.2.3 and HM-9.0.1 HM HM-9.0 defect closed 2012-12-02T08:28:45+01:00 2013-01-09T02:05:27+01:00 "Mismatch between WD session 8.7.2.3 and HM (*)TComLoopFilter::xGetBoundaryStrengthSingle() * (1) When q0(current) is P-slice and p0(neighbour) is B-slice, p0 is used as P-slice. (L1 of p0 is not used) * (2) HM is getting the RefIdx of pcCUP (neighbouring block) and use pcSlice (current block) reference list to find the reference picture and then compare reference pictures. Thus this step may be incorrect. In my understanding, it should find the reference picture of the neighbouring block and not the reference index " sue.naing HM-9.0 884 DBF issue for multi slice HM HM-9.0 defect closed 2012-12-02T11:14:42+01:00 2012-12-02T11:21:45+01:00 "In HM-9.0.1, DBF uses the parameter of slice which appeared last of the picture even if there are multi slice in a picture. In TDecGop::filterPicture(TComPic*& rpcPic) TComSlice* pcSlice = rpcPic->getSlice(rpcPic->getCurrSliceIdx()); CurrSliceIdx() should be the largest value instead of starting from zero. Therefore, pcSlice should be the last slice. In following function, m_pcLoopFilter->setCfg(pcSlice->getPPS()~~->getDeblockingFilterControlPresentFlag(), pcSlice~~->getDeblockingFilterDisable(), pcSlice->getDeblockingFilterBetaOffsetDiv2(), pcSlice->getDeblockingFilterTcOffsetDiv2(), bLFCrossTileBoundary); I think the parameters used in the function should be below the last slice only. " sue.naing HM-9.0 887 bug in merge mode motion vector derivation HM HM-9.0 defect closed 2012-12-02T22:19:29+01:00 2013-02-04T10:32:32+01:00 "In TDecEntropy::decodePUWise(), TComMvField cMvFieldNeighbours[] is not reinitialized when the CU contains more than one PU with merge_flag equal to 1. This causes incorrectly derived merging candidates: {{{ diff --git a/source/Lib/TLibDecoder/TDecEntropy.cpp b/source/Lib/TLibDecoder/TDecEntropy.cpp index 07dd3ee..c9ec01a 100644 --- a/source/Lib/TLibDecoder/TDecEntropy.cpp +++ b/source/Lib/TLibDecoder/TDecEntropy.cpp @@ -155,7 +155,6 @@ Void TDecEntropy::decodePUWise( TComDataCU* pcCU, UInt uiAbsPartIdx, UInt uiDept UInt uiNumPU = ( ePartSize == SIZE_2Nx2N ? 1 : ( ePartSize == SIZE_NxN ? 4 : 2 ) ); UInt uiPUOffset = ( g_auiPUOffset[UInt( ePartSize )] << ( ( pcCU->getSlice()->getSPS()->getMaxCUDepth() - uiDepth ) << 1 ) ) >> 4; - TComMvField cMvFieldNeighbours[MRG_MAX_NUM_CANDS << 1]; // double length for mv of both lists UChar uhInterDirNeighbours[MRG_MAX_NUM_CANDS]; for ( UInt ui = 0; ui < pcCU->getSlice()->getMaxNumMergeCand(); ui++ ) @@ -172,6 +171,7 @@ Void TDecEntropy::decodePUWise( TComDataCU* pcCU, UInt uiAbsPartIdx, UInt uiDept decodeMergeFlag( pcCU, uiSubPartIdx, uiDepth, uiPartIdx ); if ( pcCU->getMergeFlag( uiSubPartIdx ) ) { + TComMvField cMvFieldNeighbours[MRG_MAX_NUM_CANDS << 1]; // double length for mv of both lists decodeMergeIndex( pcCU, uiPartIdx, uiSubPartIdx, ePartSize, uhInterDirNeighbours, cMvFieldNeighbours, uiDepth ); UInt uiMergeIndex = pcCU->getMergeIndex(uiSubPartIdx); if ( pcCU->getSlice()->getPPS()->getLog2ParallelMergeLevelMinus2() && ePartSize != SIZE_2Nx2N && pcSubCU->getWidth( 0 ) <= 8 ) }}} " stefane HM-9.0 854 Multi-slice QP setting in one frame is not supported by HM9.0 HM HM-9.0 enhancement closed 2012-11-20T12:20:13+01:00 2013-01-19T17:33:05+01:00 "In TAppEncCfg.cpp: if ( m_pchdQPFile ) { FILE* fpt=fopen( m_pchdQPFile, ""r"" ); if ( fpt ) { Int iValue; Int iPOC = 0; while ( iPOC < m_iFrameToBeEncoded ) { if ( fscanf(fpt, ""%d"", &iValue ) == EOF ) break; m_aidQP[ iPOC ] = iValue; iPOC++; } fclose(fpt); } } The current HM can only load one QP for the whole frame. Multi-slice in one frame coding with different QP is not available. " xx.cai HM-9.0 866 Order of operations in SEI writing HM HM-9.0 enhancement closed 2012-11-28T14:17:25+01:00 2013-01-22T16:11:54+01:00 "Leading SEI messages (for which all values are values are known in advance) can be written into the bitstream before encoding the picture. This would help to align the order of NAL units in the trace file with the actual order in the bitstream." ksuehring HM-9.0 870 Include assertion in TComOutputBitstream::write() HM HM-9.0 enhancement closed 2012-11-30T02:42:29+01:00 2013-01-09T14:05:57+01:00 "There is no check in TComOutputBitstream::write(UInt uiBits, UInt uiNumberOfBits) function to see if the size of the variable to be written, uiBits, does not exceed uiNumberOfBits bits. I suggest an assertion be included so that even if someone accidentally assigns a larger value to uiBits, this assertion would catch it. If the size of uiBits is more than uiNumberOfBits bits, (the way the write() function is currently written) there may be no errors thrown by the code, and some of the preceding syntax elements may have wrong values when decoding the bitstream. The attached patch adds the assertion to the write() function." adarsh HM-9.0 871 Code related to zig-zag and NSQT scans in HM9.0 HM HM-9.0 enhancement closed 2012-11-30T03:23:44+01:00 2012-11-30T03:53:16+01:00 "There is code related to the zig-zag and NSQT scans in several functions, which is not used anymore. Find attached a patch removing the code related to this for HM-9.0-dev rev3097." joel HM-9.0 874 Dependent slice neighborhood cleanup HM HM-9.0 enhancement closed 2012-11-30T17:59:54+01:00 2013-01-19T17:35:42+01:00 The check for bEnforceDependentSliceRestriction in TComPattern::getPU* is not necessary for dependent slices (slice segments) after the removal of entropy slices. This code can be removed. ksuehring HM-9.0 886 TComSlice::m_bCheckLDC not computed for P slices HM HM-9.0 defect closed 2012-12-02T22:02:30+01:00 2012-12-02T22:25:35+01:00 "TComSlice::m_bCheckLDC is only computed for B slices. It is also needed in P slices: {{{ diff --git a/source/Lib/TLibDecoder/TDecTop.cpp b/source/Lib/TLibDecoder/TDecTop.cpp index 210835c..f65b324 100644 --- a/source/Lib/TLibDecoder/TDecTop.cpp +++ b/source/Lib/TLibDecoder/TDecTop.cpp @@ -497,7 +497,7 @@ Bool TDecTop::xDecodeSlice(InputNALUnit &nalu, Int &iSkipFrame, Int iPOCLastDisp pcSlice->setRefPic(pcSlice->getRefPic(REF_PIC_LIST_0, iRefIdx), REF_PIC_LIST_1, iRefIdx); } } - if (pcSlice->isInterB()) + if (!pcSlice->isIntra()) { Bool bLowDelay = true; Int iCurrPOC = pcSlice->getPOC(); }}} " stefane HM-8.1 799 five_minus_max_num_merge_cand HM HM-8.1 defect closed 2012-10-16T07:53:54+02:00 2012-10-18T05:55:34+02:00 The syntax element five_minus_max_num_merge_cand shall only be present for P and B slices. fuldseth HM-8.1 821 Bug in HM8.2 HM HM-8.1 defect closed 2012-11-01T23:19:54+01:00 2012-11-01T23:27:03+01:00 "In TDecCAVLC.cpp line 340 in HM8.2 version setSarWidth(uiCode) should be setSarHeight(uiCode) I do not know the proper protocol for changing the code... but this is an obvious error. Cheers James Michener James@Michener.com" michener HM-8.1 827 mismatch between text and software for initialization value of sao_type_idx contexts HM HM-8.1 defect closed 2012-11-05T11:03:50+01:00 2013-01-07T17:00:20+01:00 "In the file source/Lib/TLibCommon/ContextTables.h, the array INIT_SAO_TYPE_IDX is initialized as ; static const UChar INIT_SAO_TYPE_IDX[3][NUM_SAO_TYPE_IDX_CTX] = { { 200, }, { 185, }, { 160, }, }; This is different from the spec. The array should be initialized as : static const UChar INIT_SAO_TYPE_IDX[3][NUM_SAO_TYPE_IDX_CTX] = { { 160, }, { 185, }, { 200, }, }; " PhuongNguyen HM-8.1 794 Incorrect Parameter Set Map Sizes HM HM-8.1 defect closed 2012-10-11T00:32:17+02:00 2012-10-18T06:10:17+02:00 "The size of the SPS and PPS arrays are set incorrectly in the following function. There can be up to 32 SPS and up to 256 PPS. {{{ ParameterSetManagerDecoder::ParameterSetManagerDecoder() : m_vpsBuffer(MAX_NUM_VPS) , m_spsBuffer(256) , m_ppsBuffer(16) { } }}} The attached patch can be used to fix the problem." bheng HM-8.1 801 class diagram HM HM-8.1 defect closed 2012-10-17T05:10:40+02:00 2012-10-19T07:43:38+02:00 who could draw the class diagram of the HM8? shakingWaves HM-8.1 803 programming style HM HM-8.1 defect closed 2012-10-20T06:06:41+02:00 2012-10-20T06:33:25+02:00 I have browered some source code of HM-8.1.I have understood that thefunction of TAppCommon Project is lexical analysis.I have try to representit with UML,but I failed,because of the programe style is not pure object-oriented.they are the mixed of object-oriented and procedual-orientedprograme style. shakingWaves HM-8.1 818 Multiple SPS with same ID HM HM-8.1 defect closed 2012-10-31T10:20:23+01:00 2012-11-22T10:53:19+01:00 "Assuming that multiple SPS with the same ID are allowed by the standard, the HM decoder does not seem to work properly. Problem description: HM allocates a buffer containing new SPS each time it received new SPS. With the second SPS with same ID, it frees previous SPS buffer. However, previously decoded slice is not yet output and still has its SPS buffer pointer referring to freed buffer. When this decoded slice is output (after reading slice header of next IDR), it uses corrupted SPS parameters from freed buffer then crashes. " fuldseth HM-8.1 819 Mismatch between encoder and decoder with respect to hrd parameters HM HM-8.1 defect closed 2012-10-31T14:21:54+01:00 2012-11-01T23:28:18+01:00 "Temporal layers are interpreted differently in encoder and decoder: TEncCavlc.cpp: for( i = 0; i <= pcSPS->getMaxTLayers(); i ++ ) TDecCavlc.cpp: for( i = 0; i < pcSPS->getMaxTLayers(); i ++ ) Causes mismatch between encoder and decoder with respect to hrd parameters. " Kenneth HM-8.1 820 User defined tile structure causes encoder crash HM HM-8.1 defect closed 2012-10-31T14:34:07+01:00 2012-11-01T23:29:16+01:00 "The encoder crash when specifying user defined tiles structures, e.g. UniformSpacingIdc=0, NumTileRowsMinus1=2, RowHeightArray = 4 4 4, NumTileColumnsMinus1, ColumnWidthArray = 6 7 7 The reason is in TEncCfg.h where m_iNumColumnsMinus1 and m_iNumRowsMinus1 not are interpreted correctly." Kenneth HM-8.1 800 cleanup; remove unused wpp flush-related tests and functions HM HM-8.1 technical change closed 2012-10-16T10:01:43+02:00 2012-10-18T05:37:04+02:00 " Two patches based on 8.1-dev, release 2870 to remove no longer used functionality related to wpp flushing. Doesn't affect any results in common test conditions or wpp encoded streams. wpp1: A no-longer-relevant test is removed from both the encoder and decoder relating to the detection of a WPP substream crossing a line of LCUs. This condition is no longer possible with the enforced substream-per-line. wpp2: Removal of no longer needed functions based on codeFlush and decodeFlush in encoder and decoder. " gordon HM-8.1 813 HM8.2 bug in SAO + IPCM + Lossless HM HM-8.1 defect closed 2012-10-25T07:13:22+02:00 2012-10-25T10:59:38+02:00 "The current bit shift computation in xPCMSampleRestoration is not correct when the IPCM bit depth is not equal to the internal bit depth and both lossless and IPCM are enabled. The bug should be fixed. Attachment is a bug fix patch for HM-8.2-dev. The fix requires only two line changes." kchono HM-8.0 791 Encoded bit stream cause segmentation fault in decoder when using IDR in DecodingRefreshType HM HM-8.0 defect closed 2012-10-05T23:02:11+02:00 2012-11-30T01:03:40+01:00 When encoding using encoder_randomaccess_main.cfg. Only change in cfg is to use IDR for DecodingRefreshType. It seems to be related to POC calculation. xiaosong HM-8.0 712 wrong initValue for split_transform_flag ctxIdx HM HM-8.0 defect closed 2012-09-04T09:48:14+02:00 2013-01-07T17:07:43+01:00 "according to DRAFT8, Table 9-22, there is 9 CABAC init context elements for split_transform_flag like below, {153, 138, 138, 124, 138, 94, 224, 167, 122} and the ctxIdxOffset is 0,3,6 for each initType 0,1,2. But in HM, for every initType(0,1,2), init value written like below static const UChar INIT_TRANS_SUBDIV_FLAG[3][NUM_TRANS_SUBDIV_FLAG_CTX] = { { 153, 138, 138, }, { 124, 138, 94, }, { 224, 167, 122, }, }; Because of SLICE_TYPE_ORDER in previous HM, I think that we need to reorder this array.." louis.lee HM-8.0 746 removal of HHI_AMP_OFF macro and extraneous syntax in SPS HM HM-8.0 defect closed 2012-09-15T00:54:23+02:00 2012-09-15T13:30:40+02:00 "In HM-8.0, the HHI_AMP_OFF macro is undefined. The only place this macro is used is in xInitSPS() in TEncTop.cpp. #if HHI_AMVP_OFF for ( i = 0; i < g_uiMaxCUDepth; i++ ) { m_cSPS.setAMVPMode( i, AM_NONE ); } #else for ( i = 0; i < g_uiMaxCUDepth; i++ ) { m_cSPS.setAMVPMode( i, AM_EXPL ); } #endif These extraneous AMVPMode flags are written in the SPS in conflict with the DIS text. It is strongly suggested to remove the AMVPMode syntax elements and also remove AMVPMode flags as clean up. I am attaching a suggested patch. " dthoang HM-8.0 798 algorithm of deciding block availability doesn't work well if in a dependent slice HM HM-8.0 defect closed 2012-10-16T03:36:17+02:00 2012-12-02T11:05:09+01:00 " {{{ if ( (bEnforceSliceRestriction && (m_pcCUAbove==NULL || m_pcCUAbove->getSlice()==NULL || m_pcCUAbove->getSCUAddr()+uiAPartUnitIdx < m_pcPic->getCU( getAddr() )->getSliceStartCU(uiCurrPartUnitIdx))) || (bEnforceDependentSliceRestriction && (m_pcCUAbove==NULL || m_pcCUAbove->getSlice()==NULL || m_pcCUAbove->getSCUAddr()+uiAPartUnitIdx < m_pcPic->getCU( getAddr() )->getDependentSliceStartCU(uiCurrPartUnitIdx))) || (bEnforceTileRestriction &&(m_pcCUAbove==NULL || m_pcCUAbove->getSlice()==NULL || (m_pcPic->getPicSym()->getTileIdxMap( m_pcCUAbove->getAddr() ) != m_pcPic->getPicSym()->getTileIdxMap(getAddr())))) ) { return NULL; } }}} The function '''TComDataCU::getPUAbove''' returns NULL when the slice of current LCU is dependent slice, the slice of above LCU is dependent/independent slice and the slice of above-right LCU is '''independet'''. It is a mismatch with the clause 6.4 in WD. The start CU address of the slice(getSliceStartCU) is referred when deciding block availability as you can confirm in the following code. I think that it affects to make wrong decision. In addition, it seems that #643 ticket and this problem are caused by same reason. It need to be correct in the view of HM stabiliy testing as well as clearing mismatch with WD." kimduckyeon HM-8.0 646 Incorrect interpretation of collocated_from_l0_flag. HM HM-8.0 defect closed 2012-07-27T21:25:02+02:00 2012-09-28T18:25:38+02:00 " The HM 7.2 software interprets the collocated_from_l0_flag=0 to mean List0 and collocated_from_l0_flag=1 to mean List1. This is the opposite meaning when compared with the WD text. The attached patch can be used to fix this mismatch." bheng HM-8.0 661 HM8.0 software manual typo HM HM-8.0 defect closed 2012-08-08T00:19:01+02:00 2012-09-05T12:42:25+02:00 "SEI digest option name in software manual is different from that of HM8.0. The manual uses ""SEIPictureDigest"", while HM8.0 uses ""SEIpictureDigest"". There is a mismatch in the letter ""P"". " junxu HM-8.0 662 Error in getTemporalNestingFlag() HM HM-8.0 defect closed 2012-08-08T00:25:26+02:00 2012-08-20T01:07:07+02:00 "This is w.r.t. HM8.0. The definition of getTemporalNestingFlag() method in class TComVPS() is mistakenly given as Bool getTemporalNestingFlag () { return m_uiMaxLayers; } It should be Bool getTemporalNestingFlag () { return m_bTemporalIdNestingFlag; } " adarsh HM-8.0 669 HM-8.0: Enabling dependent slices causes encoder/decoder mismatch. HM HM-8.0 defect closed 2012-08-08T20:54:40+02:00 2012-08-13T15:42:22+02:00 "(No entry for HM-8.0 in the tracker) Encoding a sequence with the following added to the cfg: {{{ DependentSliceMode : 2 DependentSliceArgument : 15000 CabacIndependentFlag : 0 }}} causes digest mismatches when running the decoder." pieterkapsenberg HM-8.0 670 HM-8.0 reads beyond end of arrays with transform skip on HM HM-8.0 defect closed 2012-08-09T10:09:22+02:00 2012-08-16T11:56:13+02:00 "Valgrind reports two issues that are only present when transform skip is on. The relevant valgrind reports are below. ==6808== Invalid read of size 1 ==6808== at 0x456A58: TComDataCU::getTransformSkip(unsigned int, TextType) (TComDataCU.h:336) ==6808== by 0x45FF1A: TEncSearch::xRecurIntraChromaCodingQT(TComDataCU*, unsigned int, unsigned int, TComYuv*, TComYuv*, TComYuv*, unsigned int&) (TEncSearch.c pp:2186) ==6808== by 0x460697: TEncSearch::xRecurIntraChromaCodingQT(TComDataCU*, unsigned int, unsigned int, TComYuv*, TComYuv*, TComYuv*, unsigned int&) (TEncSearch.c pp:2347) ==6808== by 0x460697: TEncSearch::xRecurIntraChromaCodingQT(TComDataCU*, unsigned int, unsigned int, TComYuv*, TComYuv*, TComYuv*, unsigned int&) (TEncSearch.c pp:2347) ==6808== by 0x462A2F: TEncSearch::estIntraPredChromaQT(TComDataCU*, TComYuv*, TComYuv*, TComYuv*, TComYuv*, unsigned int) (TEncSearch.cpp:2839) ==6808== by 0x43C9FB: TEncCu::xCheckRDCostIntra(TComDataCU*&, TComDataCU*&, PartSize) (TEncCu.cpp:1431) ==6808== by 0x43942D: TEncCu::xCompressCU(TComDataCU*&, TComDataCU*&, unsigned int, PartSize) (TEncCu.cpp:707) ==6808== by 0x43A052: TEncCu::xCompressCU(TComDataCU*&, TComDataCU*&, unsigned int, PartSize) (TEncCu.cpp:856) ==6808== by 0x43A052: TEncCu::xCompressCU(TComDataCU*&, TComDataCU*&, unsigned int, PartSize) (TEncCu.cpp:856) ==6808== by 0x437C4E: TEncCu::compressCU(TComDataCU*&) (TEncCu.cpp:235) ==6808== by 0x47662C: TEncSlice::compressSlice(TComPic*&) (TEncSlice.cpp:908) ==6808== by 0x4441EC: TEncGOP::compressGOP(int, int, TComList&, TComList&, std::list >&) (TEncGOP .cpp:581) ==6808== Address 0x60479b0 is 0 bytes after a block of size 16 alloc'd ==6808== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==6808== by 0x485130: TComDataCU::create(unsigned int, unsigned int, unsigned int, bool, int, bool) (TComDataCU.cpp:166) ==6808== by 0x436DD2: TEncCu::create(unsigned char, unsigned int, unsigned int) (TEncCu.cpp:83) ==6808== by 0x41D380: TEncTop::create() (TEncTop.cpp:97) ==6808== by 0x4184DB: TAppEncTop::xCreateLib() (TAppEncTop.cpp:285) ==6808== by 0x418635: TAppEncTop::encode() (TAppEncTop.cpp:329) ==6808== by 0x406CC9: main (encmain.cpp:75) ==6808== Invalid read of size 1 ==6808== at 0x4C26040: memcpy (mc_replace_strmem.c:497) ==6808== by 0x45E9C2: TEncSearch::xLoadIntraResultQT(TComDataCU*, unsigned int, unsigned int, bool) (TEncSearch.cpp:1909) ==6808== by 0x45C81E: TEncSearch::xRecurIntraCodingQT(TComDataCU*, unsigned int, unsigned int, bool, TComYuv*, TComYuv*, TComYuv*, unsigned int&, unsigned int& , bool, double&) (TEncSearch.cpp:1533) ==6808== by 0x4619DA: TEncSearch::estIntraPredQT(TComDataCU*, TComYuv*, TComYuv*, TComYuv*, TComYuv*, unsigned int&, bool) (TEncSearch.cpp:2605) ==6808== by 0x43C911: TEncCu::xCheckRDCostIntra(TComDataCU*&, TComDataCU*&, PartSize) (TEncCu.cpp:1427) ==6808== by 0x4394E5: TEncCu::xCompressCU(TComDataCU*&, TComDataCU*&, unsigned int, PartSize) (TEncCu.cpp:713) ==6808== by 0x43A052: TEncCu::xCompressCU(TComDataCU*&, TComDataCU*&, unsigned int, PartSize) (TEncCu.cpp:856) ==6808== by 0x43A052: TEncCu::xCompressCU(TComDataCU*&, TComDataCU*&, unsigned int, PartSize) (TEncCu.cpp:856) ==6808== by 0x43A052: TEncCu::xCompressCU(TComDataCU*&, TComDataCU*&, unsigned int, PartSize) (TEncCu.cpp:856) ==6808== by 0x437C4E: TEncCu::compressCU(TComDataCU*&) (TEncCu.cpp:235) ==6808== by 0x47662C: TEncSlice::compressSlice(TComPic*&) (TEncSlice.cpp:908) ==6808== by 0x4441EC: TEncGOP::compressGOP(int, int, TComList&, TComList&, std::list >&) (TEncGOP .cpp:581) ==6808== Address 0x664f140 is 0 bytes after a block of size 64 alloc'd ==6808== at 0x4C24A72: operator new[](unsigned long) (vg_replace_malloc.c:305) ==6808== by 0x45937F: TEncSearch::init(TEncCfg*, TComTrQuant*, int, int, int, int, TEncEntropy*, TComRdCost*, TEncSbac***, TEncSbac*) (TEncSearch.cpp:275) ==6808== by 0x41EBDB: TEncTop::init() (TEncTop.cpp:342) ==6808== by 0x418545: TAppEncTop::xInitLib() (TAppEncTop.cpp:300) ==6808== by 0x418644: TAppEncTop::encode() (TAppEncTop.cpp:330) ==6808== by 0x406CC9: main (encmain.cpp:75) " stworrall HM-8.0 671 DeltaQpRD mismatch when multiple slices are used HM HM-8.0 defect karlsharman closed 2012-08-13T15:39:56+02:00 2015-03-25T16:39:13+01:00 When DeltaQpRD is enabled and multiple slices (also dependent slices) are used, encoder and decoder mismatch. ksuehring HM-8.0 673 cabac_init_flag determination broken for entropy slices HM HM-8.0 defect closed 2012-08-14T01:05:58+02:00 2012-08-15T14:48:15+02:00 "If currently in a dependent slice, and the slice it depends on has mvd_l1_zero_flag = 1, getSlice()->getMvdL1ZeroFlag() does not return the correct value. Specifically, this affects the parsing process here: TDecSbac::parseMvd, line 850: {{{ if(pcCU->getSlice()->getMvdL1ZeroFlag() && eRefList == REF_PIC_LIST_1 && pcCU->getInterDir(uiAbsPartIdx)==3) }}} " pieterkapsenberg HM-8.0 675 HM can crash in windows when disabling SAO. HM HM-8.0 defect closed 2012-08-15T19:17:32+02:00 2012-08-16T11:41:49+02:00 "In Windows, there is a crash related to uninitialized variables not being 0 by default (unlike gcc), when encoding with SAO off. Suggested fix in TEncTop.cpp, xGetNewPicBuffer() {{{ #if REMOVE_APS // fixed condition, only allocate if SAO enabled. if (m_bUseSAO) { rpcPic->getPicSym()->allocSaoParam(&m_cEncSAO); } #endif }}} " pieterkapsenberg HM-8.0 680 HM does not use default scale of 16 for transform_skip TUs when scaling lists are present. HM HM-8.0 defect closed 2012-08-17T23:14:09+02:00 2012-08-29T18:13:18+02:00 "The text specifies: If transform_skip_enabled is equal to 1 and SizeID is equal to 0, ScalingList[ SizeID ][ MatrixID ][ i ] is set equal to 16 for i=0..15 HM does not implement this, 4x4's are still scaled with the custom list when transform_skip_enabled is true." pieterkapsenberg HM-8.0 681 Potential bug in TComPrediction::motionCompensation HM HM-8.0 defect closed 2012-08-21T08:33:57+02:00 2012-08-22T22:34:22+02:00 "There are below lines in TComPrediction::motionCompensation() if( pcCU->getSlice()->getPPS()->getUseWP()) { xPredInterUni (pcCU, uiPartAddr, iWidth, iHeight, eRefPicList, pcYuvPred, iPartIdx, true ); } else { xPredInterUni (pcCU, uiPartAddr, iWidth, iHeight, eRefPicList, pcYuvPred, iPartIdx ); } xPredInterUni (pcCU, uiPartAddr, iWidth, iHeight, eRefPicList, pcYuvPred, iPartIdx ); I think the last xPredInterUni() is unnecessary. This problem may be caused by removal the macro of WEIGHT_PRED. Please refer to http://hevc.kw.bbc.co.uk/trac/changeset/1840/branches/HM-5.1-dev-cleanup/source/Lib/TLibCommon/TComPrediction.cpp for more information. In my opinion, the line 482(474) should be removed together with WEIGHT_PRED." libin HM-8.0 696 nal_unit_type mismatch between HM-8.0 and D8 (J1003) d7 HM HM-8.0 defect closed 2012-08-28T00:39:58+02:00 2012-09-28T19:49:56+02:00 There are mismatches on values of nal_unit_type between HM-8.0 (TLibCommon/CommonDef.h) and Table 7-1 of JCTVC-J1003_d7.doc. yamakage HM-8.0 700 Derivation process of chroma offset in WP when an input bit depth is beyond 8bit HM HM-8.0 defect closed 2012-08-29T02:25:52+02:00 2012-12-03T21:32:36+01:00 "When an input bit depth is beyond 8bit, the derivation process of chroma offset in the weighted prediction is incorrect. Since the value of chroma offset is always held in 8bit (see equations (8-224) and (8-225)), the predicted value of chroma offset must be also held in 8bit. The original source code in the function of TDecCavlc::xParsePredWeightTable( TComSlice* pcSlice ) should be modified simply as follows (same for TEncCavlc): --------- '''Original;''' Int shift = ((1<<(g_uiBitDepth+g_uiBitIncrement-1))); --------- '''Modified;''' Int shift = 128; The modified patch is provided in this ticket. " Tanizawa HM-8.0 701 Potential issue in HM8.0 regarding interPred HM HM-8.0 defect closed 2012-08-29T12:57:08+02:00 2012-09-28T18:25:37+02:00 "In HM8.0, In File: TComDataCU.cpp In Funct: TComDataCU::xGetColMVP() Colocated picture is selected as follows: // use coldir. TComPic *pColPic = getSlice()->getRefPic( RefPicList(getSlice()->isInterB() ? getSlice()->getColDir() : 0), getSlice()->getColRefIdx()); As per JCTVC-J1003_d7.doc section 8.5.2.1.7 ""– If slice_type is equal to B and collocated_from_l0_flag is equal to 0, the variable colPic specifies the picture that contains the collocated partition as specified by RefPicList1[ collocated_ref_idx ]."" Not sure but it seems the above mentioned code should be as follows: TComPic *pColPic = getSlice()->getRefPic( RefPicList(getSlice()->isInterB() ? (1-getSlice()->getColDir()) : 0), getSlice()->getColRefIdx()); " pankaj0iit HM-8.0 709 Coding Mismatch between HM8.0dev and WD on short_term_ref_pic_set_idx HM HM-8.0 defect bbross closed 2012-08-30T18:11:35+02:00 2012-11-30T04:16:00+01:00 "In JCTVC-J1003_d7.doc, short_term_ref_pic_set_idx of slice_header is coded with u(v) while HM8.0dev seems coded with ue(v). " exf001 HM-8.0 713 Visual Studio 2005 project setting does not include source/Lib/TLibCommon/NAL.h HM HM-8.0 defect closed 2012-09-04T17:22:11+02:00 2012-09-05T12:39:33+02:00 When Visual Studio 2005 is used, the project does not include source/Lib/TLibCommon/NAL.h. This file needs to be added into build/vc8/TLibCommon_vc8.vcproj. obici HM-8.0 714 Typo in assert condition HM HM-8.0 defect closed 2012-09-04T17:32:30+02:00 2012-09-05T13:01:07+02:00 "In Void TComDataCU::setPredModeSubParts( PredMode eMode, UInt uiAbsPartIdx, UInt uiDepth ), the assert condition: assert( sizeof( *m_pePartSize) == 1 ); uses m_pePartSize instead of m_pePredMode." obici HM-8.0 716 overriding IntraPeriod causes encoder crash when used with encoder_intra_main.cfg HM HM-8.0 defect closed 2012-09-04T22:43:49+02:00 2012-11-02T07:28:57+01:00 "Loading encoder_intra_main.cfg and then overriding IntraPeriod on the command line with a value higher than 1 causes the encoder to crash. " dthoang HM-8.0 717 HM-8.0 cannot compile with Visual Studio 2012 HM HM-8.0 defect closed 2012-09-05T03:35:26+02:00 2012-09-05T14:20:23+02:00 "The error reported is that mem_fun is not defined in TEncGOP.cpp. #include in that file will solve that problem." libin HM-8.0 727 mismatch between the WD text and the HM software on derivation of spatial merging candidates HM HM-8.0 defect closed 2012-09-10T13:31:40+02:00 2012-11-22T12:25:19+01:00 "In 8.5.2.1.2 the text specifies a number of conditions for inclusion of a candidate in the merge list such as: – (xP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (xN >> (log2_parallel_merge_level_minus2 + 2)) and (yP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (yN >> (log2_parallel_merge_level_minus2 + 2)). – singleMCLFlag is equal to 0 and PartMode of the current prediction unit is PART_2NxN or PART_2NxnU or PART_2NxnD and partIdx is equal to 1 and N is equal to B1 – singleMCLFlag is equal to 0 and PartMode of the current prediction unit is PART_Nx2N or PART_nLx2N or PART_nRx2N and partIdx is equal to 1 and N is equal to A1 – N is equal to B2 and the prediction units covering luma location ( xA1, yA1 ) and luma location ( xN, yN ) have the same motion vectors and the same reference indices In the software if the ""parallel merge"" test results in a particular candidate N not being added to the list then that N is not tested for equivalence when a subsequent candidate is considered. However if a particular candidate N is not added as the current PU is the second partition of a 2 partition CU then that N is still used for the equivalence test when a subsequent candidate is considered. See TComDataCU::getInterMergeCandidates() Intuitively it would seem that a candidate should not be excluded from the list just because it has the same MV and RefIdx as another candidate that was not added to the list. " asimpson HM-8.0 728 Decoder stops on assert when EnableTMVPFlag = 1, ColDir = 1 and NumRexIdx(REF_PIC_LIST_0) > 1 HM HM-8.0 defect closed 2012-09-10T14:47:01+02:00 2012-09-10T15:24:39+02:00 "This bug occures when EnableTMVPFlag = 1, ColDir = 1 and NumRexIdx(REF_PIC_LIST_0) > 1 Reference decoder parses Slice header of first slice in the picture twice (except the very first slice). First - when variable m_bFirstSliceInPicture is false and second - when this variable is true. When m_bFirstSliceInPicture is false decoder initializes current slice data by data of previous slice (just in case the current slice is dependent one I believe), when m_bFirstSliceInPicture is true – by default values. Let’s consider what will happen if current slice is the first slice of P picture following after B picture in decoding order. Last slice of B picture had ColDir = 1. Default values for ColDir is 0. In code below the ""'''collocated_ref_idx'''"" will be read if ColDir == 0 (right case for P_SLICE, second pass of slice header parsing) and won’t be read if ColDir == 1 (first pass of slice header parsing). So when decoder is trying to parse Slice header for the first time with wrong value of ColDir it skips reading of ""'''collocated_ref_idx'''"" , brokes CABAC decoding and stops on some asserts (see example in attachment) if ( rpcSlice->getEnableTMVPFlag() ) { if ( rpcSlice->getSliceType() == B_SLICE ) { READ_FLAG( uiCode, ""collocated_from_l0_flag"" ); rpcSlice->setColDir(uiCode); } if ( rpcSlice->getSliceType() != I_SLICE && ((rpcSlice->getColDir()==0 && rpcSlice->getNumRefIdx(REF_PIC_LIST_0)>1)|| (rpcSlice->getColDir() ==1 && rpcSlice->getNumRefIdx(REF_PIC_LIST_1)>1))) { READ_UVLC( uiCode, ""'''collocated_ref_idx'''"" ); rpcSlice->setColRefIdx(uiCode); } } The bug could be easily fixed for example by initializing of ColDir to 0 (rpcSlice->setColDir(0);) before line “if ( rpcSlice->getSliceType() == B_SLICE )” " deryzhov HM-8.0 734 HM8.0 bug in SAO + PCM + lossless HM HM-8.0 defect closed 2012-09-12T19:01:12+02:00 2012-09-27T22:58:49+02:00 "1) In HM8.0, when ALF is removed from the software, TComAdaptiveLoopFilter::PCMLFDisableProcess() was also removed, although it is necessary to prevent SAO from altering PCM or lossless-coded CUs. 2) Even if we revert the function, it has a bug as discribed below. PCMLFDisableProcess() calls xPCMRestoration(). xPCMRestoration() calls xPCMCURestoration() for each CU if (pcm_enabled_flag = 1 and pcm_loop_filter_disable_flag = 1) OR transquant_bypass_enable_flag = 1. xPCMCURestoration() restores the unfiltered pixel values with the following condition: if ((pcCU->getIPCMFlag(uiAbsZorderIdx)) || pcCU->isLosslessCoded( uiAbsZorderIdx)) This should be corrected as follows: if ((pcCU->getIPCMFlag(uiAbsZorderIdx) && pcPic->getSlice(0)->getSPS()->getPCMFilterDisableFlag()) || pcCU->isLosslessCoded( uiAbsZorderIdx)) The current condition ignores pcm_loop_filter_disable_flag, so it misjudges when pcm_enabled_flag = 1 pcm_loop_filter_disable_flag = 0 transquant_bypass_enable_flag = 1 pcm_flag = 1 cu_transquant_bypass_flag = 0 Because pcm_loop_filter_disable_flag = 0, this I_PCM CU should be SAO filtered, but with the current condition it won't. " madhukar HM-8.0 735 HM8.0 bug in DBLK + lossless HM HM-8.0 defect closed 2012-09-12T19:04:07+02:00 2012-09-27T22:51:35+02:00 "Deblocking filter implmentation has a problem when both PCM and lossless is enabled at the same time. In TComLoopFilter::xEdgeFilterLuma() (similar in TComLoopFilter::xEdgeFilterChroma()), {{{ Bool bPCMFilter = (pcCU->getSlice()->getSPS()->getUsePCM() && pcCU->getSlice()->getSPS()->getPCMFilterDisableFlag())? true : false; Bool bPartPNoFilter = false; Bool bPartQNoFilter = false; .... for ( UInt iIdx = 0; iIdx < uiNumParts; iIdx++ ) ... if (bPCMFilter) { // Check if each of PUs is I_PCM bPartPNoFilter = (pcCUP->getIPCMFlag(uiPartPIdx)); bPartQNoFilter = (pcCUQ->getIPCMFlag(uiPartQIdx)); } // check if each of PUs is lossless coded bPartPNoFilter = bPartPNoFilter || (pcCUP->isLosslessCoded(uiPartPIdx) ); bPartQNoFilter = bPartQNoFilter || (pcCUQ->isLosslessCoded(uiPartQIdx) ); ... }}} When bPCMFilter = false (pcm_enabled_flag = 0 or pcm_loop_filter_disable_flag = 0), bPartPNoFilter (and bPartQNoFilter) is not reset in the for loop. Therefore, once it becomes true by a lossless-coded CU, it remains true for the rest of the loop. This disables the deblocking filter process for incorrect edges. So, this part should be replaced with the following, for example (or equivalent code): // Check if each of PUs is I_PCM bPartPNoFilter = bPCMFilter && (pcCUP->getIPCMFlag(uiPartPIdx)); // Modified bPartQNoFilter = bPCMFilter && (pcCUQ->getIPCMFlag(uiPartQIdx)); // Modified // check if each of PUs is lossless coded bPartPNoFilter = bPartPNoFilter || (pcCUP->isLosslessCoded(uiPartPIdx) ); bPartQNoFilter = bPartQNoFilter || (pcCUQ->isLosslessCoded(uiPartQIdx) );" madhukar HM-8.0 737 decoder crashes when active pps id is not equal to zero HM HM-8.0 defect closed 2012-09-13T02:29:13+02:00 2012-09-28T20:41:25+02:00 "This bug occurs when the active pps id is not equal to zero. The current HM reference decoder always assumes that the active PPS id is equal to zero and will crash if it is not. {{{ Bool TDecTop::xDecodeSlice(...) { ... //!!!KS: DIRTY HACK m_apcSlicePilot->setPPSId(0); m_apcSlicePilot->setPPS(m_parameterSetManagerDecoder.getPrefetchedPPS(0)); }}}" zhyang123 HM-8.0 738 HM8.0 encoder bug in checking the ranges of max TU depths HM HM-8.0 defect closed 2012-09-13T03:14:43+02:00 2013-01-09T01:14:06+01:00 "See the following code in xCheckParameter(). According to the spec description, the ""'''m_uiQuadtreeTULog2MaxSize'''"" should be replaced by the value of log2(m_uiMaxCUWidth). Otherwise, the encder does not work if we set the max TU depth to 5 in the default cfg files. xConfirmPara( m_uiQuadtreeTUMaxDepthInter > '''m_uiQuadtreeTULog2MaxSize''' - m_uiQuadtreeTULog2MinSize + 1, ""QuadtreeTUMaxDepthInter must be less than or equal to the difference between QuadtreeTULog2MaxSize and QuadtreeTULog2MinSize plus 1"" ); xConfirmPara( m_uiQuadtreeTUMaxDepthIntra > '''m_uiQuadtreeTULog2MaxSize''' - m_uiQuadtreeTULog2MinSize + 1, ""QuadtreeTUMaxDepthIntra must be less than or equal to the difference between QuadtreeTULog2MaxSize and QuadtreeTULog2MinSize plus 1"" );" rickxu HM-8.0 739 decoder failed when there are different PPSs using same id HM HM-8.0 defect closed 2012-09-13T03:40:26+02:00 2012-09-28T20:01:37+02:00 "This bug occurs when there are different PPSs using the same pic_parameter_set_id value. The current HM decoder conducts the deblocking and ALF process when a slice of a new picture is detected. So if a different PPS using the same pic_parameter_set_id precedes that new slice, the PPS content of the current picture will be overridden and the deblocking process of the current picture will hence use the incorrect PPS info. {{{ bNewPicture = m_cTDecTop.decode(nalu, m_iSkipFrame, m_iPOCLastDisplay); if (bNewPicture) { bitstreamFile.clear(); bitstreamFile.seekg(location-streamoff(3)); bytestream.reset(); } bPreviousPictureDecoded = true; if (bNewPicture || !bitstreamFile) { m_cTDecTop.executeDeblockAndAlf(uiPOC, pcListPic, m_iSkipFrame, m_iPOCLastDisplay); } }}} " zhyang123 HM-8.0 747 Slice deblocking_filter_override_flag is not handled correctly HM HM-8.0 defect closed 2012-09-15T03:12:14+02:00 2012-09-15T12:14:10+02:00 "The following code from 8.0-dev appears to override slice-level deblocking parameters without checking the value of the slice deblocking_filter_override_flag. {{{ if (pcSlice->getPPS()->getDeblockingFilterControlPresentFlag()) { if(pcSlice->getPPS()->getDeblockingFilterOverrideEnabledFlag()) { pcSlice->setDeblockingFilterDisable(pcSlice->getPPS()->getPicDisableDeblockingFilterFlag()); if (!pcSlice->getDeblockingFilterDisable()) { pcSlice->setDeblockingFilterBetaOffsetDiv2(pcSlice->getPPS()->getDeblockingFilterBetaOffsetDiv2()); pcSlice->setDeblockingFilterTcOffsetDiv2(pcSlice->getPPS()->getDeblockingFilterTcOffsetDiv2()); } } } }}} In addition, I believe these slice level parameters are already inherited from the PPS (when deblocking_filter_override_flag=0) during syntax parsing in TDecCavlc::parseSliceHeader( ). In which case, the above code could be deleted. A proposed patch is attached. " bheng HM-8.0 749 VPS encoder/decoder mismatch HM HM-8.0 defect closed 2012-09-16T12:45:50+02:00 2012-09-18T11:36:33+02:00 "Reading or writing of the VPS syntax elements seems to be broken (which does not have any effect on decoding because these syntax elements are currently ignored). The trace file (#define ENC_DEC_TRACE 1) differs as follows: encoder: {{{ 0 video_parameter_set_id u(4) : 0 1 vps_temporal_id_nesting_flag u(1) : -1 }}} decoder: {{{ 0 video_parameter_set_id u(4) : 15 1 vps_temporal_id_nesting_flag u(1) : 1 }}} Also a flag should never be ""-1"". " ksuehring HM-8.0 750 Temporal_id is incorrect when TARGET_DECLAYERID_SET is 1 HM HM-8.0 defect closed 2012-09-17T15:37:25+02:00 2012-09-27T22:37:14+02:00 When TARGET_DECLAYERID_SET is 1 (which it is by default in HM-8.0) the temporal_id is set to 0 in the NAL unit header (on the encoder side) for all pictures regardless of the value of temporal_id in the config file. jonatan HM-8.0 751 undefined reference in software-manual.tex HM HM-8.0 defect closed 2012-09-17T23:42:46+02:00 2012-09-27T19:46:32+02:00 "Latex reports the following warning: LaTeX Warning: Reference `sec:gop-structure' on page 7 undefined on input line 655. Suggested fix is to add ""\label{sec:gop-structure}"" right after ""\subsection{GOP structure table}"". " dthoang HM-8.0 755 "Potential Bug in ""TEncSearch,cpp""" HM HM-8.0 defect closed 2012-09-19T10:39:35+02:00 2012-09-27T21:51:50+02:00 "1555 if(uiSingleCbfU == 0) 1556 { 1557 pcCU ->setTransformSkipSubParts ( 0, TEXT_CHROMA_U, uiAbsPartIdx, uiFullDepth ); 1558 bestModeIdUV[0] = 0; 1559 } 1560 if(uiSingleCbfV == 0) 1561 { 1562 pcCU ->setTransformSkipSubParts ( 0, TEXT_CHROMA_V, uiAbsPartIdx, uiFullDepth ); 1563 bestModeIdUV[0] = 0; 1564 } 1565 } Should Line 1563 be as follows? 1563 bestModeIdUV[1] = 0; " kazushi HM-8.0 760 Incorrect return type of getColRefIdx() HM HM-8.0 defect closed 2012-09-21T14:15:03+02:00 2012-09-28T21:09:43+02:00 Function getColRefIdx should return UInt instead of Bool. m_colRefIdx could be more than 1. deryzhov HM-8.0 761 Return type of getColRefIdx HM HM-8.0 defect closed 2012-09-22T04:58:31+02:00 2012-09-28T21:09:43+02:00 The return type of the function getColRefIdx() in TComSlice.h, which is a member of class TComSlice, should be UInt. Currently, the return type is Bool, which could give erroneous value when the colRefIdx is more than one. The attached patch (w.r.t r2764, HM8.0-dev) has a solution. adarsh HM-8.0 776 collocated_ref_idx parsing at decoder HM HM-8.0 defect closed 2012-09-26T00:41:58+02:00 2012-09-28T21:01:12+02:00 "The collocated_ref_idx is parsed at the decoder in TDecCAVLC.cpp. However, when the syntax elements are not signalled, no value is explicitly assigned there. When there are multiple slices and one of these syntax elements is not signalled, it takes the value of the syntax element from the previous slice - because copySliceInfo() is called to copy the information from the previous slice. The fix is similar to fix for #728 (for colDir) fixed in r2753." adarsh HM-8.0 784 confusing part_mode initialization HM HM-8.0 defect closed 2012-09-28T21:07:29+02:00 2014-01-12T02:24:55+01:00 "{{{ static const UChar INIT_PART_SIZE[3][NUM_PART_SIZE_CTX] = { { 154, 139, CNU, CNU, }, { 154, 139, CNU, CNU, }, { 184, CNU, CNU, CNU, }, }; }}} binIdx=2 is used. Should be: {{{ static const UChar INIT_PART_SIZE[3][NUM_PART_SIZE_CTX] = { { 154, 139, 154, CNU, }, { 154, 139, 154, CNU, }, { 184, CNU, CNU, CNU, }, }; }}} CNU happens to be 154, so functionally it is correct, just confusing. " sorin HM-8.0 785 Error in de-blocking HM HM-8.0 defect closed 2012-09-29T00:09:57+02:00 2012-11-28T15:11:26+01:00 "There looks like an error in the deblocking code. Since it is identical in the encoder and decoder, it doesn't show up in common test conditions. The following line of code (and two other similar occurences) in TComLoopFilter::xGetBoundaryStrengthSingle() is erroneous. iRefIdx = pcCUP->getCUMvField(REF_PIC_LIST_0)->getRefIdx(uiPartP); piRefP0 = (iRefIdx < 0) ? NULL : (Int*) pcSlice->getRefPic(REF_PIC_LIST_0, iRefIdx); pcSlice is the slice containing current CU (and partition Q), while pcCUP (partition P) could be from another slice; the second line should therefore be iRefIdx = pcCUP->getCUMvField(REF_PIC_LIST_0)->getRefIdx(uiPartP); piRefP0 = (iRefIdx < 0) ? NULL : (Int*) pcCUP->getSlice()->getRefPic(REF_PIC_LIST_0, iRefIdx); Similar changes for similar occurences (all in the same function) as above. Attached patch solves this issue." adarsh HM-8.0 788 compile problem of HTM 5.1 under CentOS HM HM-8.0 defect closed 2012-09-29T14:33:28+02:00 2012-09-29T17:01:30+02:00 " When I compile 3DV-HTM 5.1 under linux, it has some error message make[1]: *** [objects/TRenModel.d.o] Error 1 make[1]: Leaving directory `HTM/build/linux/lib/TLibRenderer' make: *** [all] Error 2 How could I solve this problem? (My OS is CentOS.) Many thanks!!" cttsai HM-8.0 789 Chroma bit depth should be used in filtering process HM HM-8.0 defect closed 2012-10-04T15:44:38+02:00 2012-11-02T08:26:12+01:00 "In Void TComLoopFilter::xEdgeFilterChroma, the luma bit depth ""g_uiBitIncrement+g_uiBitDepth""is used to calculate tc: Int iBitdepthScale = (1<<(g_uiBitIncrement+g_uiBitDepth-8)); Int iIndexTC = Clip3(0, MAX_QP+DEFAULT_INTRA_TC_OFFSET, iQP + DEFAULT_INTRA_TC_OFFSET*(ucBs - 1) + (m_tcOffsetDiv2 << 1)); Int iTc = tctable_8x8[iIndexTC]*iBitdepthScale; This should be the chroma bit depth but I cannot find a corresponding BitDepthC in HM. In SPS, only QpBdOffsetC is set." bbross HM-8.0 795 When FramesTobeEncoded > actual num frames, encoder report is different HM HM-8.0 defect closed 2012-10-13T04:10:12+02:00 2012-11-02T07:25:00+01:00 "I encoded the 150-frame Traffic sequence, but mistakenly specified 300 frames as FramesToBeEncoded. The encoder ran fine, but the reported rate and maybe PSNR averages were not the same as when I specified FramesToBeEncoded to be 150. I didn't yet repeat the test so someone may want to doublecheck this on a short sequence to see if this is a bug. " cohen HM-8.0 822 Wavefront crashed when input source only has one LCU column HM HM-8.0 defect closed 2012-11-02T07:07:54+01:00 2012-11-02T07:52:27+01:00 "Wavefront crashed when input source only has one LCU column. In that case, the top right LCU is not available, however HM8.0 accesses the address of it before loading the context information. Lines 865 and 1143 in TEncSlice.cpp and line 248 in TDecSlice.cpp: if ( (uiCUAddr != 0) && ( pcCUTR->getSCUAddr()+uiMaxParts-1 >= pcSlice->getSliceCurStartCUAddr() ) && bAllowDependence) should be modified to: if ( (uiCUAddr != 0) && ( pcCUTR && pcCUTR->getSCUAddr()+uiMaxParts-1 >= pcSlice->getSliceCurStartCUAddr() ) && bAllowDependence)" xx.cai HM-8.0 895 Add new header files & source files HM HM-8.0 defect closed 2012-12-09T09:15:50+01:00 2013-01-09T00:46:27+01:00 I am very sorry to report the problem,because I know that this is not the bug.I am confused.I want to add some new header files and source files in the project to do some test.for example ,I want to add a new header file TVideoIOYuvDataPrint.h and a new source file TVideoIOYuvDataPrint.cpp in the project TLibVideoIO ,but I do not know where the header file and source file should be placed.I do not which floder they shoud be placed and I do not know which files should be edited.I just hope you all could help me.thank you very much! shakingWaves HM-8.0 1082 Missing left shift on offset in merge evaluation in SAO HM HM-8.0 defect closed 2013-05-02T18:00:05+02:00 2013-11-14T20:43:07+01:00 "merge_iOffset in TEncSampleAdaptiveOffset.cpp needs to be shifted left by m_auiSaoBitIncrease[channel] in saoComponentParamDist and sao2ChromaParamDist. " karlsharman HM-8.0 703 five_minus_max_num_merge_cand configurability HM HM-8.0 enhancement closed 2012-08-30T02:04:53+02:00 2012-09-28T19:24:56+02:00 "The maximum number of merge candidates should be a configurable parameter rather than a hard-coded value (MRG_MAX_NUM_CANDS_SIGNALED), particularly on the decoder side. I believe the attached patch can be used to fix this issue. With this patch, the maximum number of merge candidates can be controlled from the encoder config files, and the decoder will use whatever value is signaled in the slice header. " bheng HM-8.0 715 Removal of two obsolete functions HM HM-8.0 enhancement closed 2012-09-04T17:45:39+02:00 2012-09-04T18:39:18+02:00 "The following two functions are obsolete and never called in HM: Void TComDataCU::xCheckDuplicateCand Void TComDataCU::xCheckCornerCand" obici HM-8.0 756 Some checks of TemporalId are missing in the decoder HM HM-8.0 enhancement closed 2012-09-19T14:11:19+02:00 2012-09-19T14:40:22+02:00 "The DIS text says: ""when nal_unit_type is in the range of 3 to 6, inclusive (coded slice of a TSA or STSA picture), TemporalId shall not be equal to 0."" and ""If nal_unit_type is equal to VPS_NUT, SPS_NUT, EOS_NUT, or EOB_NUT, TemporalId shall be equal to 0."" These restrictions are not checked in the decoder. " rickard HM-8.0 676 Bulding HM8 in lynux HM HM-8.0 task closed 2012-08-15T20:38:57+02:00 2012-08-15T20:49:05+02:00 "Hi i am beginner in HEVC i want to know how to compile HM in RHEL 6 when i run .\makefile in Linux build it says commend not found please help me on the above matter" satyaec49 HM-8.0 748 m_fracBits is not reset when entering a new tile HM HM-8.0 defect closed 2012-09-15T14:52:26+02:00 2014-04-09T18:44:10+02:00 "This is a trivial bug of HM8.0 encoder. Before encoding a new tile, all the variables of RD cabac coder are reset, except m_fracBits. It may have very very small impact on coding results, but fixing it will ensure the intention of independent tile. it's proposed to modify Void TEncBinCABAC::start() { m_uiLow = 0; m_uiRange = 510; m_bitsLeft = 23; m_numBufferedBytes = 0; m_bufferedByte = 0xff; } to Void TEncBinCABAC::start() { m_uiLow = 0; m_uiRange = 510; m_bitsLeft = 23; m_numBufferedBytes = 0; m_bufferedByte = 0xff; #if FAST_BIT_EST m_fracBits = 0; #endif }" Wenhao.Zhang HM-8.0 781 """TansformSkip"" should be ""TransformSkip""" HM HM-8.0 defect closed 2012-09-27T11:17:24+02:00 2012-09-27T21:45:32+02:00 """TansformSkip"", as shown below, should be renamed as ""TransformSkip"". ===== kazushi@avlxc[1011] cd source/ kazushi@avlxc[1012] ls App Lib kazushi@avlxc[1013] grep TansformSkip */*/* App/TAppEncoder/TAppEncCfg.cpp: (""TS"", m_useTansformSkip, false, ""Intra transform skipping"") App/TAppEncoder/TAppEncCfg.cpp: (""TSFast"", m_useTansformSkipFast, false, ""Fast intra transform skipping"") App/TAppEncoder/TAppEncCfg.cpp: printf(""TS:%d "", m_useTansformSkip ); App/TAppEncoder/TAppEncCfg.cpp: printf(""TSFast:%d "", m_useTansformSkipFast ); App/TAppEncoder/TAppEncCfg.h: Bool m_useTansformSkip; ///< flag for enabling intra transform skipping App/TAppEncoder/TAppEncCfg.h: Bool m_useTansformSkipFast; ///< flag for enabling fast intra transform skipping App/TAppEncoder/TAppEncTop.cpp: m_cTEncTop.setUseTransformSkip ( m_useTansformSkip ); App/TAppEncoder/TAppEncTop.cpp: m_cTEncTop.setUseTransformSkipFast ( m_useTansformSkipFast ); Lib/TLibCommon/TComSlice.cpp:, m_useTansformSkip (false) Lib/TLibCommon/TComSlice.cpp:, m_useTansformSkipFast (false) Lib/TLibCommon/TComSlice.cpp:, m_useTansformSkip (false) Lib/TLibCommon/TComSlice.h: Bool m_useTansformSkip; Lib/TLibCommon/TComSlice.h: Bool m_useTansformSkipFast; Lib/TLibCommon/TComSlice.h: Bool getUseTransformSkip () { return m_useTansformSkip; } Lib/TLibCommon/TComSlice.h: Void setUseTransformSkip ( Bool b ) { m_useTansformSkip = b; } Lib/TLibCommon/TComSlice.h: Bool getUseTransformSkipFast () { return m_useTansformSkipFast; } Lib/TLibCommon/TComSlice.h: Void setUseTransformSkipFast ( Bool b ) { m_useTansformSkipFast = b; } Lib/TLibCommon/TComSlice.h: Bool m_useTansformSkip; Lib/TLibCommon/TComSlice.h: Bool getUseTransformSkip () { return m_useTansformSkip; } Lib/TLibCommon/TComSlice.h: Void setUseTransformSkip ( Bool b ) { m_useTansformSkip = b; } Lib/TLibCommon/TComTrQuant.cpp: Bool useRDOQForTransformSkip = !(m_useTansformSkipFast && pcCU->getTransformSkip(uiAbsPartIdx,eTType)); Lib/TLibCommon/TComTrQuant.cpp: m_useTansformSkipFast = useTransformSkipFast; Lib/TLibCommon/TComTrQuant.h: Bool m_useTansformSkipFast; Lib/TLibEncoder/TEncCfg.h: Bool m_useTansformSkip; Lib/TLibEncoder/TEncCfg.h: Bool m_useTansformSkipFast; Lib/TLibEncoder/TEncCfg.h: Bool getUseTransformSkip () { return m_useTansformSkip; } Lib/TLibEncoder/TEncCfg.h: Void setUseTransformSkip ( Bool b ) { m_useTansformSkip = b; } Lib/TLibEncoder/TEncCfg.h: Bool getUseTransformSkipFast () { return m_useTansformSkipFast; } Lib/TLibEncoder/TEncCfg.h: Void setUseTransformSkipFast ( Bool b ) { m_useTansformSkipFast = b; } Lib/TLibEncoder/TEncSbac.cpp: UInt useTansformSkip = pcCU->getTransformSkip( uiAbsPartIdx,eTType); Lib/TLibEncoder/TEncSbac.cpp: m_pcBinIf->encodeBin( useTansformSkip, m_cTransformSkipSCModel.get( 0, eTType? TEXT_CHROMA: TEXT_LUMA, 0 ) ); Lib/TLibEncoder/TEncSbac.cpp: DTRACE_CABAC_V( useTansformSkip ) Lib/TLibEncoder/TEncTop.cpp: ,m_useTansformSkipFast Lib/TLibEncoder/TEncTop.cpp: m_cSPS.setUseTransformSkip ( m_useTansformSkip ); Lib/TLibEncoder/TEncTop.cpp: m_cPPS.setUseTransformSkip( m_useTansformSkip ); " kazushi HM-7.2 666 Compiler error in 32-bit build HM HM-7.2 defect davidf closed 2012-08-08T06:40:07+02:00 2012-09-05T12:50:43+02:00 " Compiler error on a 32-bit build (present since HM-7.2): .../source/Lib/TLibCommon/TComTrQuant.cpp:2225: error: integer constant is too large for ""long"" type Root cause: Missing 64-bit size qualifier in constant at .../source/Lib/TLibCommon/CommonDef.h:115 (integer constants are 32-bit unless forced otherwise) Offending code: #define MAX_INT64 0x7FFFFFFFFFFFFFFF ///< max. value of signed 64-bit integer Corrected code: #define MAX_INT64 0x7FFFFFFFFFFFFFFFLL ///< max. value of signed 64-bit integer Change: Addition of 'LL' (long long) suffix to constant " bhaskar HM-7.2 643 PUs are considered not available if in a different dependent slice (HM-7.2) HM HM-7.2 defect closed 2012-07-26T10:24:29+02:00 2012-11-30T17:56:36+01:00 "In HM-7.2, the function TComDataCU::getPULeft returns NULL when the current slice is a dependent slice and the left PU is in another slice. This is a mismatch with the text clause 6.4. Specifically, this condition needs to be corrected: {{{ if ( (bEnforceSliceRestriction && (m_pcCULeft==NULL || m_pcCULeft->getSlice()==NULL || m_pcCULeft->getSCUAddr()+uiLPartUnitIdx < m_pcPic->getCU( getAddr() )->getSliceStartCU(uiCurrPartUnitIdx))) || (bEnforceDependentSliceRestriction && (m_pcCULeft==NULL || m_pcCULeft->getSlice()==NULL || m_pcCULeft->getSCUAddr()+uiLPartUnitIdx < m_pcPic->getCU( getAddr() )->getDependentSliceStartCU(uiCurrPartUnitIdx))) || (bEnforceTileRestriction && ( m_pcCULeft==NULL || m_pcCULeft->getSlice()==NULL || (m_pcPic->getPicSym()->getTileIdxMap( m_pcCULeft->getAddr() ) != m_pcPic->getPicSym()->getTileIdxMap(getAddr())) ) ) ) { return NULL; } }}} " pieterkapsenberg HM-7.2 678 Problem with Merging, Bug allows merging across slices for first row/column. HM HM-7.2 defect closed 2012-08-17T06:56:16+02:00 2012-11-30T17:44:37+01:00 "Problem in TEncSampleAdaptiveOffset::rdoSaoUnit() function, The following code checks valid slice/tile for non first row and non first column, but i think that should not be case. If first line contains two slices, it will still try merge left and similarly vertically as well. {{{ if (rx!=0) { // check tile id and slice id if ( (m_pcPic->getPicSym()->getTileIdxMap(addr-1) != m_pcPic->getPicSym()->getTileIdxMap(addr)) || (m_pcPic->getCU(addr-1)->getSlice()->getSliceIdx() != m_pcPic->getCU(addr)->getSlice()->getSliceIdx())) { allowMergeLeft = 0; } } if (ry!=0) { if ( (m_pcPic->getPicSym()->getTileIdxMap(addr-m_iNumCuInWidth) != m_pcPic->getPicSym()->getTileIdxMap(addr)) || (m_pcPic->getCU(addr-m_iNumCuInWidth)->getSlice()->getSliceIdx() != m_pcPic->getCU(addr)->getSlice()->getSliceIdx())) { allowMergeUp = 0; } } }}}" amitkchawla HM-7.1 602 Division by small number leads to WP overflow HM HM-7.1 defect closed 2012-07-01T08:05:56+02:00 2012-07-22T10:40:04+02:00 "In line 230 of WeighPredAnalysis.cpp, iRefAC may be small, leading to a large value of dWeight: Double dWeight = (iRefAC==0) ? (Double)1.0 : ( (Double)(iCurrAC) / (Double)iRefAC); dWeight should be clipped to an appropriate range " fbossen HM-7.1 603 Incorrect chroma offset in WP HM HM-7.1 defect closed 2012-07-01T08:17:30+02:00 2012-07-03T01:16:53+02:00 "In the weighted prediction process, a chroma adjustment is defined in the semantics of delta_chroma_offset_l0: ChromaOffsetL0[ i ][ j ] = (delta_chroma_offset_l0[i][j] – 
( (shift*ChromaWeightL0[ i ][ j ]) >> ChromaLog2WeightDenom ) − shift ) where shift is 1 << BitDepth In the HM, the shift value is set to the incorrect value of g_uiIBDI_MAX>>1 (e.g., 127 instead of 128). For example in line 2694 of TDecCAVLC.cpp: wp[j].iOffset = iDeltaChroma - ( ( (g_uiIBDI_MAX>>1)*wp[j].iWeight)>>(wp[j].uiLog2WeightDenom) ) + (g_uiIBDI_MAX>>1); " fbossen HM-7.1 604 Release and debug mismatch in HM-7.1 HM HM-7.1 defect closed 2012-07-01T09:10:10+02:00 2012-07-06T13:08:57+02:00 "When I run a test using debug mode in VS2008, the result of the first picture is different from that of the first picture of release mode. I suspect the SPS writing since only bits are different and the results of following pictures are exactly matched. intra-main, QP37, no other configurations are changed. -- debug mode POC 0 TId: 0 ( I-SLICE, nQP 37 QP 37 ) 19352 bits [Y 32.3698 dB U 37.2887 dB V 37.1861 dB] [ET 9 ] [L0 ] [L1 ] [MD5:ed5bfa 80e3e859abf556be538b4e8c13,10ebcfaa5f70b351e248e56795e05fd0,d3cced55dee740201385497af4d61f8e] POC 1 TId: 0 ( I-SLICE, nQP 37 QP 37 ) 18872 bits [Y 32.2803 dB U 37.3826 dB V 37.2286 dB] [ET 9 ] [L0 ] [L1 ] [MD5:f7629b 45cab701315431a8beb45419c7,e10ab976b6446afac30053ef90038ddf,0e70e861c2501d7ca8590910b6c672f6] -- release mode POC 0 TId: 0 ( I-SLICE, nQP 37 QP 37 ) 19280 bits [Y 32.3698 dB U 37.2887 dB V 37.1861 dB] [ET 1 ] [L0 ] [L1 ] [MD5:ed5bfa 80e3e859abf556be538b4e8c13,10ebcfaa5f70b351e248e56795e05fd0,d3cced55dee740201385497af4d61f8e] POC 1 TId: 0 ( I-SLICE, nQP 37 QP 37 ) 18872 bits [Y 32.2803 dB U 37.3826 dB V 37.2286 dB] [ET 1 ] [L0 ] [L1 ] [MD5:f7629b 45cab701315431a8beb45419c7,e10ab976b6446afac30053ef90038ddf,0e70e861c2501d7ca8590910b6c672f6] " secret9th HM-7.1 605 Invalid Video Parameter Set ID HM HM-7.1 defect closed 2012-07-03T00:33:56+02:00 2012-07-03T01:09:36+02:00 "The variable m_VPSId (video_parameter_set_id) written in the seq_parameter_set as part of VPS_INTEGRATION is used without being initialized. For instance, the value written in VS2010 debug mode is video_parameter_set_id = -858993460 (0xcccccccc). The attached patch provides one way to fix the problem. " bheng HM-7.1 607 Decoder crashes on entropy slices HM HM-7.1 defect closed 2012-07-04T16:03:42+02:00 2012-07-13T17:28:13+02:00 "In HM-7.1-dev (revision 2488), when encoding sequences with DependentSliceMode 2, DependentSliceArgument 15000 and CabacIndependentFlag 1, there are mismatches and occasional decoder crashes. For instance, I found that all 416x240 sequences encoded with cfg/encoder_randomaccess_main.cfg (with the three parameters changed as above) at qp 22 all make the decoder crash." rickard HM-7.1 608 compilation fails using g++-4.7.1: strict-aliasing warning HM HM-7.1 defect closed 2012-07-04T17:05:32+02:00 2012-07-05T23:43:48+02:00 "Compilation fails whit g++-4.7.1 (strict-aliasing warning) on Linux Debian (unstable, amd64) Compiles without any problems with g++-4.4.5, other versions not tested. {{{ HM-7.1-dev/build/linux/lib/TLibCommon/ ../../../../source/Lib/libmd5/libmd5.c:143:28: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] HM-7.1-dev/build/linux/lib/TLibCommon/ ../../../../source/Lib/libmd5/libmd5.c:144:28: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] cc1plus: all warnings being treated as errors }}}" jhanca HM-7.1 611 Fix for dependent slices required HM HM-7.1 defect closed 2012-07-09T13:56:48+02:00 2012-07-13T17:27:35+02:00 Especially, fixes are required for tiles_or_entropy_coding_sync_idc equal to 0 and 1. thomass HM-7.1 620 decoder memory leak HM HM-7.1 defect closed 2012-07-13T11:50:46+02:00 2012-07-14T21:31:20+02:00 The TAppDecTop::xFlushOutput() caused memory leak at decoder when DYN_REF_FREE is 0. The reconstructed pictures in DPB are not released. ywhe HM-7.1 623 LCU based SAO parameters still stored in APS structure HM HM-7.1 defect closed 2012-07-14T18:35:18+02:00 2012-08-09T14:37:29+02:00 "After the removal of that SAO parameters from the APS these are still stored in structures inside the TComAPS class. With the C-Style memory allocation from outside this creates memory leaks at the decoder because the APS contents are never disposed. Especially the parameter set manager cannot destroy these parameters because it would need a pointer to the SAO class to call the proper memory disposal methods. All parameter storage classes should be able to destruct properly without needing pointers to function classes." ksuehring HM-7.1 626 Text/HM mismatch of aps_id in slice header HM HM-7.1 defect closed 2012-07-16T03:08:04+02:00 2012-08-19T15:20:21+02:00 in current text, aps_id will be parsed only alf is enabled in slice header, but in HM7.1, aps_id is parsed when alf or SAO or deblocking filter is enabled. C.Lai HM-7.1 628 IDR decoding crashes on reference picture handling HM HM-7.1 defect closed 2012-07-19T16:23:43+02:00 2012-11-30T01:03:39+01:00 "When changing the following option in encoder_randomaccess_main.cfg: DecodingRefreshType : 2 # Random Accesss 0:none, 1:CDR, 2:IDR The encoder output is as follows: ... POC 23 TId: 0 ( b-SLICE, nQP 36 QP 36 ) 824 bits [Y 31.7512 dB U 35. 7221 dB V 38.8283 dB] [ET 3 ] [L0 22 20 ] [L1 24 22 ] [MD5:ea7b549bff0a3f 4ed23f51c4787015a7,ce5c0eb5eedbdca19a423da76ca6340f,78d6e2cf45ed837a11fbe4b5e543 1610] POC 32 TId: 0 ( I-SLICE, nQP 32 QP 32 ) 63304 bits [Y 34.5371 dB U 38. 2891 dB V 38.8579 dB] [ET 1 ] [L0 ] [L1 ] [MD5:7dd675682622aceb58a8d60c6b f4c34f,5ee761cf32b5c9f89a6b16f9304150e2,070c01c0f6cfca19413c7413b2ad936b] POC 28 TId: 0 ( B-SLICE, nQP 34 QP 34 ) 16256 bits [Y 31.4156 dB U 36. 6092 dB V 37.2534 dB] [ET 5 ] [L0 0 ] [L1 0 ] [MD5:45da0160626b684dee66e0 350f1d0942,5bd4e33ab0c4f83f6f8f87956367599d,f50f0a1a6eccaa923b39261b5ddae493] POC 26 TId: 0 ( B-SLICE, nQP 35 QP 35 ) 8416 bits [Y 30.7287 dB U 36. 2384 dB V 37.0700 dB] [ET 5 ] [L0 -4 0 ] [L1 -4 0 ] [MD5:e7c5f6f97c9380d7 5992c3b4fcb7368c,a28f3ec26b16b74d26bd94090b9f5e11,88c770253a716fe01dc4dbe3fdff45 14] POC 25 TId: 0 ( b-SLICE, nQP 36 QP 36 ) 2360 bits [Y 29.7619 dB U 35. 8614 dB V 36.7713 dB] [ET 4 ] [L0 -6 -4 ] [L1 -6 -4 ] [MD5:2285197ba0a12f df719cc6ee0e6bc29f,96e1c57f1b8632b1f77c27f31086fd46,fc2019edb56f802999f8ffaeb8a3 2e21] POC 27 TId: 0 ( b-SLICE, nQP 36 QP 36 ) 2392 bits [Y 30.3157 dB U 36. 1520 dB V 37.0221 dB] [ET 4 ] [L0 -6 -4 ] [L1 -4 0 ] [MD5:952fcdbddfe90bb d59d2187f6a384e7a,00287140b1b218eacaa6e543d889eadc,379282acbab7bbdb95c34269de148 1ca] POC 30 TId: 0 ( B-SLICE, nQP 35 QP 35 ) 6728 bits [Y 31.5007 dB U 37. 0231 dB V 37.3884 dB] [ET 6 ] [L0 -4 -6 ] [L1 0 -4 ] [MD5:bec5d27453f6548 cb50388df2e51e2dd,bd2c6c8d1d63b20412100f4883dd702d,d71b55a6475cf9141019af00500ac a2e] POC 29 TId: 0 ( b-SLICE, nQP 36 QP 36 ) 2528 bits [Y 30.5533 dB U 36. 3313 dB V 37.0537 dB] [ET 4 ] [L0 -4 -2 ] [L1 -2 0 ] [MD5:7e549af60931b1f fc0e31bee931c5cd0,57797358d3b6149707ad38bde0c7bb1e,51dbffe830f2d30c9c4a5de241340 aac] POC 31 TId: 0 ( b-SLICE, nQP 36 QP 36 ) 2888 bits [Y 31.3209 dB U 37. 1631 dB V 37.3709 dB] [ET 4 ] [L0 -2 -4 ] [L1 0 -2 ] [MD5:d0b745622174813 7e013ffe7b9c9bb5f,abbe22e2a468949c3c7945df3e473cb5,738702b1b086ad0c80463a5a058bc 379] POC 40 TId: 0 ( B-SLICE, nQP 33 QP 33 ) 38312 bits [Y 33.7084 dB U 37. 7730 dB V 38.4935 dB] [ET 6 ] [L0 0 ] [L1 0 ] [MD5:8f16ab6574c2e10a4a8919 7fbb593777,8939a026ebd63d9963454995ed18cd26,497e7b35f1a14cf646017590e282f20e] ... The decoder crashes on the TComPic* TComSlice::xGetRefPic (...) function in the picture following the IDR (i.e. picture -4) ... POC 23 TId: 0 ( b-SLICE, QP 36 ) [DT 0.047] [L0 22 20 ] [L1 24 22 ] [MD5:ea7b 549bff0a3f4ed23f51c4787015a7,ce5c0eb5eedbdca19a423da76ca6340f,78d6e2cf45ed837a11 fbe4b5e5431610,(OK)] POC 0 TId: 0 ( I-SLICE, QP 32 ) [DT 0.406] [L0 ] [L1 ] [MD5:7dd675682622aceb 58a8d60c6bf4c34f,5ee761cf32b5c9f89a6b16f9304150e2,070c01c0f6cfca19413c7413b2ad93 6b,(OK)] ... This because Unsigned integers are used in several functions: Void TAppDecTop::decode() TComPic* TComSlice::xGetRefPic () Void TDecTop::executeDeblockAndAlf() Additionally, negative POC can not be signaled: READ_CODE(sps->getBitsForPOC(), uiCode, ""pic_order_cnt_lsb""); " gvwallen HM-7.1 633 HM/WD mismatch. PPS num_ref_idx_l0_default_active_minus1 coding HM HM-7.1 defect closed 2012-07-20T08:41:02+02:00 2012-07-20T09:40:47+02:00 In the WD num_ref_idx_l0_default_active_minus1 and num_ref_idx_l1_default_active_minus1 in the PPS are coded with ue(v) whereas in HM they are coded with u(3) pieterkapsenberg HM-7.1 635 j0033 fix of wpp entrypoint offsets with slices HM HM-7.1 defect closed 2012-07-20T18:30:34+02:00 2012-08-20T14:52:13+02:00 "Patch based on 7.1-dev release 2449, to implement j0033 (WPP entry points simplification) which is actually a bug fix. Avoids the writing of ""zero-length"" substreams when wpp is used with slices." gordon HM-7.1 638 "Missing ""cabac_zero_word"" writing implementation in HM software" HM HM-7.1 defect closed 2012-07-23T09:12:58+02:00 2014-10-28T18:27:15+01:00 "In HEVC WD text, ""cabac_zero_word"" may be added to the end of RBSP if necessary, however, in the encoder of current HM software, there is no implementation on writing of ""cabac_zero_word""." C.Lai HM-7.1 640 Fix of deltaU calculation when ADAPTIVE_QP_SELECTION is 0 HM HM-7.1 defect closed 2012-07-24T18:23:33+02:00 2012-11-30T01:11:25+01:00 "When the macro ADAPTIVE_QP_SELECTION is set to 0 (default is 1), the variable 'deltaU' in function TComTrQuant::xQuant() is given by deltaU[uiBlockPos] = (Int)( ((Int64)abs(iLevel) * piQuantCoeff[uiBlockPos] - (iLevel<> qBits8 ); The calulation is incorrect because piQuantCoeff should be multiplied with piCoef, not iLevel. The correct derivation is as follows deltaU[uiBlockPos] = (Int)( ((Int64)abs(piCoef[uiBlockPos]) * piQuantCoeff[uiBlockPos] - (iLevel<> qBits8 ); A patch based on HM-7.1-2574 is provided to fix the problem." wangj HM-7.1 644 Intialization of variables in TComPicSym HM HM-7.1 defect closed 2012-07-26T22:07:18+02:00 2012-08-19T15:22:57+02:00 "All the member variables of class TComPicSym are not initialized to 0/NULL/appropriate value; only m_uiNumAllocatedSlice is done so. This could be a create issues if TComPicSym::destroy() is called without initialization. Possible solution: Replace existing constructor in TComPicSym.h by the following in TComPicSym.cpp TComPicSym::TComPicSym() : m_uiWidthInCU (0) , m_uiHeightInCU (0) , m_uiMaxCUWidth (0) , m_uiMaxCUHeight (0) , m_uiMinCUWidth (0) , m_uiMinCUHeight (0) , m_uhTotalDepth (0) , m_uiNumPartitions (0) , m_uiNumPartInWidth (0) , m_uiNumPartInHeight(0) , m_uiNumCUsInFrame (0) , m_apcTComSlice (NULL) , m_uiNumAllocatedSlice (0) , m_apcTComDataCU (NULL) , m_iTileBoundaryIndependenceIdr (0) , m_iNumColumnsMinus1 (0) , m_iNumRowsMinus1 (0) , m_apcTComTile (NULL) , m_puiCUOrderMap (NULL) , m_puiTileIdxMap (NULL) , m_puiInverseCUOrderMap (NULL) {}" adarsh HM-7.1 651 Mismatch with text: cu_transquant_bypass_flag is decoded for PCM blocks HM HM-7.1 defect closed 2012-08-01T18:16:59+02:00 2012-08-06T19:57:26+02:00 "The transquant_bypass flag, when enabled in the PPS, is decoded even for PCM blocks. in TDecCu::xDecodeCU {{{ if (pcCU->getSlice()->getPPS()->getTransquantBypassEnableFlag()) { m_pcEntropyDecoder->decodeCUTransquantBypassFlag( pcCU, uiAbsPartIdx, uiDepth ); } }}} I think should be changed to: {{{ if (pcCU->getSlice()->getPPS()->getTransquantBypassEnableFlag() && pcCU->getNumSucIPCM() == 0 ) { m_pcEntropyDecoder->decodeCUTransquantBypassFlag( pcCU, uiAbsPartIdx, uiDepth ); } }}}" pieterkapsenberg HM-7.1 792 Authorized Best Resume Services HM HM-7.1 defect closed 2012-10-07T12:01:07+02:00 2021-06-09T22:35:41+02:00 As a nicely written resumes will make certain you're with the best chance of getting a particular job, you might have already been searching for [http://www.resumesplanet.com/ best resume services] for a whilst. Though you may be the best at what you do, you might not be the best at making a resume. There's no shame in that, but don't be afraid since you will find lots of nicely qualified best resume services. ElijahTanksley HM-7.1 610 log2_parallel_merge_level_minus2 configurability HM HM-7.1 enhancement closed 2012-07-05T08:51:01+02:00 2012-07-22T10:36:02+02:00 "Currently in the SW, the value of the syntax element log2_parallel_merge_level_minus2 is always set to the hard-coded macro LOG2_PARALLEL_MERGE_LEVEL_MINUS2, which is defined as 0. To enable control of the log2_parallel_merge_level_minus2 value in the configuration files, some fix is needed. The attached patch provides such fix by removing two related macros (i.e., LOG2_PARALLEL_MERGE_LEVEL_MINUS2 and CU_BASED_MRG_CAND_LIST) in the SW and replacing them with a parameter ""Log2ParallelMergeLevel"" in .cfg files. Note that CU_BASED_MRG_CAND_LIST is implicitly turned on when log2_parallel_merge_level_minus2 > 1." huiyong HM-7.1 723 Inconsistency in line endings HM HM-7.1 enhancement ksuehring closed 2012-09-06T02:48:40+02:00 2012-09-29T00:40:43+02:00 "The line ending code of TEncRateCtrl.cpp and TEncRateCtrl.h (since HM-7.1) is LF, although that of any other source files is CR+LF. HM-8.0-dev r2751 still has the inconsistency. " hao HM-7.0 580 unmatch over lossless coding HM HM-7.0 defect closed 2012-06-21T07:08:57+02:00 2012-06-26T00:26:56+02:00 "When I run the lossless coding under lowdelay configuration for sequence BQSquare_416x240_60.yuv or SlideEditing_1280x720_30, the decoder does not match the encoder. Can you help to fix this problem? I use the default setting with the following flags set as 1. LosslessCuEnabled : 1 # 1: Set ""qpprime_y_zero_transquant_bypass_flag=1"" and enable the lossless mode as well as the RD-based mode selection process. TransquantBypassEnableFlag: 1 # Value of PPS flag. CUTransquantBypassFlagValue: 1 # Constant lossless-value signaling per CU, if TransquantBypassEnableFlag is 1. " spring HM-7.0 543 encoder failed when the frame size was small HM HM-7.0 defect closed 2012-05-24T18:01:56+02:00 2012-05-25T14:46:43+02:00 In TComAdaptiveLoopFilter.cpp (around line 752), yInterval could be zero and caused the crash. This could happen even though ALF was turned off in the encoder configuration. peisongc HM-7.0 595 14-bit offset issues HM HM-7.0 defect closed 2012-06-27T18:54:57+02:00 2012-07-01T04:41:00+02:00 "Offset issues w.r.t. 14-bit: in HM7.0, TComWeightPrediction::addWeightBi()and TComWeightPrediction::addWeightUni()appearing three times (luma and chroma) for each. { … Int shiftNum = IF_INTERNAL_PREC - ( g_uiBitDepth + g_uiBitIncrement ); Int shift = wp0[0].shift + shiftNum; '''may be null''' Int round = (1<<(shift-1)) * bRound; '''beget negative shift here!' … } and in HM7.0 TComInterpolationFilter::filterCopy() { … Int shift = IF_INTERNAL_PREC - ( g_uiBitDepth + g_uiBitIncrement ); '''may be null''' Short offset = IF_INTERNAL_OFFS + (1 << (shift - 1)); '''beget negative shift here!' … } Lightweight solution is to set ''round'' and ''offset'' to 0 when bit-depth = 14... Same issue in Draft 7 d4 (Cf. [http://hevc.kw.bbc.co.uk/trac/ticket/594 Ticket #594]) Any thoughts? " pandrivon HM-7.0 597 encoder-only fix for rdFactor calculation for HE10 settings HM HM-7.0 defect closed 2012-06-28T23:09:28+02:00 2012-07-01T04:32:12+02:00 "The variable ‘rdFactor’ for computing rd-cost in the RDOQ function is currently given by Int rdFactor = (Int)((Double)(g_invQuantScales[m_cQP.rem()]*g_invQuantScales[m_cQP.rem()]<<(2*m_cQP.m_iPer))/m_dLambda/16 + 0.5) ; The calculation is based on 8-bit coding (g_uiBitIncrement = 0). It should be computed as follows, so that it also works for the HE10 setting where g_uiBitIncrement = 2. Int rdFactor = (Int)((Double)(g_invQuantScales[m_cQP.rem()])*(Double)(g_invQuantScales[m_cQP.rem()])*(Double)(1<<(2*m_cQP.m_iPer))/m_dLambda/16/(Double)(1<<(2*g_uiBitIncrement)) + 0.5); A patch is provided to fix the rdFactor calculation. This fix only affects HE10 settings when RDOQ is enabled. With this fix, on average (-0.13%, -0.32%, -0.54%) BD-rate gain were observed for AI-HE10, RA-HE10 and LB-HE10 settings. " wangj HM-7.0 530 Encoder/decoder mismatch when chroma QP offsets are used HM HM-7.0 defect closed 2012-05-07T13:11:20+02:00 2014-10-15T17:45:47+02:00 "It occurs on the 5th picture of the stream generated with the following command line : bin/TAppEncoderStatic -c cfg/encoder_lowdelay_P_main.cfg -c cfg/per-sequence/BasketballPass.cfg -f 8 -q 37 --ChromaQpOffset=-4 --ChromaQpOffset2nd=4" tkunlin HM-7.0 539 Deblocking Filter Incorrect when Minimum Transform Size is not 4x4. HM HM-7.0 defect closed 2012-05-18T00:40:58+02:00 2012-06-26T01:10:24+02:00 "Some portions of the LoopFilter code assume that the ""BaseUnit"" is always 4-pixels. However, this assumption is only true when the minimum transform size is 4x4. With any other minimum transform size, only the first four pixels out of each 8, 16, or 32 pixel edge are actually filtered by the HM software. The attached patch could be used to fix the issues. " bheng HM-7.0 541 Tiles coding broken after slice_type value change HM HM-7.0 defect closed 2012-05-24T11:47:17+02:00 2012-05-30T18:18:31+02:00 Coding of tiles causes an encoder-decoder mismatch after the values of slice_type have been changed. This is caused by a hard-coded slice_type value in the cabac_init_flag related code. ksuehring HM-7.0 545 Typo in picture padding/cropping. HM HM-7.0 defect closed 2012-05-24T22:43:07+02:00 2012-05-25T14:43:37+02:00 "There is a typo in the following section of TAppEncCfg::parseCfg( ) that is requiring 4:2:0 picture heights to have an odd number of luma samples instead of preventing that from happening. {{{ if (m_aiPad[1] % TComSPS::getCropUnitY(CHROMA_420) != 1) { fprintf(stderr, ""Error: picture height is not an integer multiple of the specified chroma subsampling\n""); exit(EXIT_FAILURE); } }}} The ""!= 1"" should be ""!= 0"". " bheng HM-7.0 546 TComPic::m_SEIs should be initialized to NULL in constructor HM HM-7.0 defect closed 2012-05-25T02:31:29+02:00 2012-05-25T14:47:13+02:00 "The variable m_SEIs of class TComPic is not initialized to NULL in the constructor of TComPic. It's only initialized in the member function create(). An error occurs sometimes in function TDecTop::xGetNewPicBuffer() where constructor TComPic::TComPic() (""rpcPic = new TComPic();"") could be followed by a call to TComPic::destroy() (""rpcPic->destroy();"") that has statement ""delete m_SEIs;"". " adarsh HM-7.0 547 Periodic I frames in Low Delay Configuration HM HM-7.0 defect closed 2012-05-25T09:22:46+02:00 2012-06-26T00:53:48+02:00 "In the default low delay configuration file within the HM7.0, when the I frame period is set to a positive value (let's say 8) and decoding refresh type is set to zero (I frame) to create a sequence with periodic I frames, decoder crashes with the following error: Assertion failed: getPOC()+pReferencePictureSet->getDeltaPOC(i) >= pocCRA, file \source\lib\tlibcommon\tcomslice.cpp, line 542 " basakoztas HM-7.0 548 Bug fixed for intra transform skipping (I0408) to support other LUC sizes HM HM-7.0 defect closed 2012-05-27T11:22:17+02:00 2012-07-01T07:46:20+02:00 "For intra transform skipping(I0408), at decoder, a bug is fixed to enable the support of other LCU sizes besides 64x64. Under the function ""parseTransformSkipFlags"", the following three lines if(eTType!= TEXT_LUMA && uiDepth == 4) { uiDepth --; } are modified to be as follows: if(eTType!= TEXT_LUMA) { const UInt uiLog2TrafoSize = g_aucConvertToBit[pcCU->getSlice()->getSPS()->getMaxCUWidth()] + 2 - uiDepth; if(uiLog2TrafoSize == 2) { uiDepth --; } }" cuilinglan HM-7.0 549 dQP fails when Tile is enabled HM HM-7.0 defect closed 2012-05-28T12:58:36+02:00 2012-06-26T07:36:14+02:00 "CU-level delta QP fails when the sub-picture partitioning with tiles is enabled. The following simple example causes encoder crash. TAppEncoder.exe -c cfg/encoder_intra_main.cfg -c cfg/per-sequence/BQSquare.cfg --NumTileColumnsMinus1=2 --NumTileRowsMinus1=1 -f 1 -dqd 3 -aq 1 -aqr 12 The attached patch (for rev.2419 of HM-7.0-dev) fixes the issue. " hao HM-7.0 550 Context init table for merge_flag is incorrect HM HM-7.0 defect closed 2012-05-29T07:00:47+02:00 2012-05-29T12:41:40+02:00 "It appears that the context init table for merge flag is incorrect. In ContextTables.h: {{{ static const UChar INIT_MERGE_FLAG_EXT[3][NUM_MERGE_FLAG_EXT_CTX] = { #if SLICE_TYPE_ORDER { CNU, }, { 110, }, { 154, }, #else { 154, }, { 110, }, { CNU, }, #endif }; }}} This implies the B slice merge flag init is unused, and I slice is used." pieterkapsenberg HM-7.0 551 False calculation of bits needed for tile_idx_minus_1 HM HM-7.0 defect closed 2012-05-29T18:40:58+02:00 2012-11-05T23:03:34+01:00 The calculation of the number of bits needed for tile_idx_minus_1 is faulty in case the tile count is a power of 2. ChristianFeldmann HM-7.0 552 HM 7.0 crashes with tiles enabled HM HM-7.0 defect closed 2012-05-29T22:39:27+02:00 2012-05-30T18:18:31+02:00 Not entirely sure what happens, but a low_delay_main stream I created with several tiles causes an encoder crash when it runs out of bits for the slice. It appears that it is reading tile markers as CABAC data. pieterkapsenberg HM-7.0 553 Transform Subdiv flag uses CNU context when LCU size < 64x64 HM HM-7.0 defect closed 2012-05-30T20:14:39+02:00 2014-01-12T02:23:00+01:00 Because transform skip flag can be coded at depth 0 when LCU is not 64x64, the context increment can be 0, which is CNU. A proper init value should be chosen (maybe the default of 154 is ok?) pieterkapsenberg HM-7.0 554 Encoding/Decoding of tile_idx_minus_1 HM HM-7.0 defect closed 2012-05-31T16:39:54+02:00 2012-11-06T16:26:24+01:00 "The HEVC text specification states that tile_idx_minus_1 is encoded as u(v) where the software uses ae(v) in bypass mode. See the attached patch." ChristianFeldmann HM-7.0 555 inaccurate bit estimation in RDOQ for coeff_abs_level_remaining HM HM-7.0 defect closed 2012-06-01T02:44:21+02:00 2014-10-15T17:45:47+02:00 "Inaccurate bit estimation in RDOQ for coeff_abs_level_remaining because the parameter update scheme is changed. Patch and performance changes are attached." wchien HM-7.0 556 Substream offset using one too many bits HM HM-7.0 defect closed 2012-06-05T10:16:08+02:00 2012-06-26T01:54:38+02:00 "An encoder side only change -- the encoder is choosing to use one too many bits to encode substream sizes. This fix does not change common test condition results. A patch for TEncCavlc::codeTilesWPPEntryPoint is attached. " gordon HM-7.0 562 tc & beta offsets for deblocking HM HM-7.0 defect closed 2012-06-06T18:08:27+02:00 2012-08-20T00:43:24+02:00 In deblocking, m_pcLoopFilter->setCfg used tc and beta offsets of the last slice for the whole picture deblocking. If a picture used different tc and beta offsets for different slices, it can't be handled properly. peisongc HM-7.0 564 ALF slice filter flag does not look at APS flag HM HM-7.0 defect closed 2012-06-07T21:12:47+02:00 2012-06-13T12:36:08+02:00 "In TDecCAVLC.cpp, line 1787, the alf_slice_filter flag is decoded even if a component is disabled in the APS. {{{ if(sps->getUseALF()) { char syntaxString[50]; for(Int compIdx=0; compIdx< 3; compIdx++) { // if( aps filter flag [compIdx]....) { sprintf(syntaxString, ""alf_slice_filter_flag[%d]"", compIdx); READ_FLAG(uiCode, syntaxString); rpcSlice->setAlfEnabledFlag( (uiCode ==1), compIdx); // } } } }}} Similarly, the codeSliceHeader function in the encoder should be edited to match." pieterkapsenberg HM-7.0 565 Divide by zero error on streams 3 or less LCUs in height or width when ALF is enabled HM HM-7.0 defect closed 2012-06-08T02:13:17+02:00 2012-07-01T07:49:23+02:00 "The calculation of the ALF regions involves a division by a variable called xInterval and yInterval in TComAdaptiveLoopFilter.cpp, line 752 and 756. This value evaluates to 0 when the picture width/height in LCUs is 3 or less, causing a divide-by-zero. This is also an issue in the suggested text in I0157" pieterkapsenberg HM-7.0 566 Uninitialized LambdaModifier is used for large GOP sizes HM HM-7.0 defect closed 2012-06-11T17:08:58+02:00 2012-06-26T00:37:38+02:00 "The code related to config parameters LambdaModifier0 through LambdaModifier3 has two problems. First, the code does not use temporal_id to select what LambdaModifier to apply for a picture.This means that picture structures that are not dyadic will get incorrect lambdas if LambdaModifierX are specified. Second, LambdaModifierX used for temporal layers above 3 are uninitialized. In practice, this may cause severe compression efficiency losses for some pictures when the GOP size is 16 or larger. Neither of these problems affect any of the common condition picture structures. The attached patch fixes the problem by adding new initialized parameters LambdaModifier4 through LambdaModifier7, and using the temporal layer as read from the config file as index instead of selecting LambdaModifier based on the GOP size. " rickard HM-7.0 571 wrong ME algorithm name given in configuration files HM HM-7.0 defect closed 2012-06-12T20:13:13+02:00 2012-12-02T11:29:17+01:00 "In the configuration files (in folder /hevc/cfg/), under heading #====Motion Search=====, in the parameter ""FastSearch"", it is given as 0 for Full search and 1 for EPZS, in the comments. But technically this comment is wrong, as the Fast search algorithm used in HM is TZSearch algorithm that is implemented in MVC. Basically these are the brief list of fast search algorithms in H.26x codecs. H.264/AVC JM - EPZS,UMHexS,SUMHexS H.264 MVC JMVM - TZSearch (or TZS algorithm) Now in HM, the same algorithm that is implemented in JMVM is implemented, which is TZS. But from most of the JCTVC meeting files (example JCTVC D600, JCTVC B300), this is understood as EPZS algorithm and which is not (from file /source/Lib/TLibEncoder/TEncSearch.cpp)." chanduinece HM-7.0 573 skip_flag context derivation issue HM HM-7.0 defect closed 2012-06-13T03:11:35+02:00 2012-07-01T07:54:17+02:00 "According to Table 9-38, skip_flag uses left and above skip_flag to derive the context index for CABAC decoding. However, instead of storing the neighboring skip_flag, the current HM 7.0 uses the following condition to determine the value of the neighboring skip_flag {{{ if ( m_pcSlice->isIntra () ) { return false; } return ( getMergeFlag( uiPartIdx ) && getPartitionSize( uiPartIdx ) == SIZE_2Nx2N && !getQtRootCbf( uiPartIdx ) ); }}} On the other hand, the new cbf flag coding rules in HM 7.0 allows the top layer chroma cbf to be one while all child chroma cbf flags to be zero. Although the example may be useless for a smart encoder, if allowed, it will make the above mentioned condition no longer equivalent to skip_flag equal to one and hence cause inconsistency between HM and spec. Suggested fix may be either fix the spec to disallow such cases or fix the HM to use the real neighboring skip_flag value to derive the context." zhyang123 HM-7.0 574 ALF: addition and subtraction swapped for coef[2] and coef[4] HM HM-7.0 defect closed 2012-06-13T11:52:22+02:00 2012-06-26T01:27:32+02:00 "In HM-7.0, for coefficient 2 and coefficient 4, the addition and subtraction should be swapped during filter training and filtering operation. (The CD text is correct) The attached patch is for HM-7.0. This fix does not affect coding efficiency. " chihming.fu HM-7.0 575 Resolution check is wrong when CroppingMode = 1 HM HM-7.0 defect closed 2012-06-14T10:11:07+02:00 2012-06-15T23:04:54+02:00 "When frame width or frame height is not a multiple of the minimum CU size, the frame width and hieight should be padded. When CroppingMode = 1, the HM should be able to pad the frame width and hieight automatically. In TAppEncCfg.cpp line 418, a check is added to see if the number of padded pixels is a integer multiple of the specified chroma subsampling. However, the ""if (m_aiPad[1] % TComSPS::getCropUnitY(CHROMA_420) != 1)"" should be ""if (m_aiPad[1] % TComSPS::getCropUnitY(CHROMA_420) != 0)""" peterchuang HM-7.0 576 Decoding CBF flag can use CNU context HM HM-7.0 defect closed 2012-06-14T23:36:18+02:00 2014-01-12T02:50:43+01:00 In TDecSbac::parseQtCbf, the CBF flags for chroma can be decoded with a depth and context increment of 3, which get init'd with a CNU value. A proper value should be chosen instead. pieterkapsenberg HM-7.0 577 deblocker high-level syntax bug in HM-7.0-dev HM HM-7.0 defect closed 2012-06-18T20:49:57+02:00 2012-06-21T02:26:46+02:00 The decoder failed to inherit the parameters from the PPS. peisongc HM-7.0 578 IDR period of 24 results in negative POCVal HM HM-7.0 defect closed 2012-06-20T14:57:28+02:00 2012-11-30T01:02:25+01:00 "Based on configuration encoder_randomaccess_main.cfg I am encoding a stream with an IDR period of 24 by specifying -ip 24 -dr 2 on the command line. The resulting bitstream starts with an IDR picture followed by 16 B pictures. The next picture is an IDR picture (POCVal is reset to zero), followed by 23 B pictures, where the first seven pictures have a POCVal lower than zero. Those pictures are skipped by the decoder. The negative POCVals are correctly decoded from slice header (log2_max_pic_order_cnt_lsb_minus4=4 and pic_order_cnt_lsb from 249 to 255)." fpach HM-7.0 579 Decoder memory leak when decoding slices preventing 32-bit decodes of 1500 byte slices HM HM-7.0 defect closed 2012-06-20T15:01:38+02:00 2012-06-21T02:22:36+02:00 " SAO related memory is being allocated on a per-slice basis in the decoder, but not freed. This prevents 32-bit decodes of higher resolutions when 1500-bytes-per-slice is used. Adding an m_SAO.destroy() prior to the m_SAO.create() in TDecTop avoids the problem, along with some fixes introduced in m_SAO.destroy(), too. Patch (based on HM 7 development release 2445) attached." gordon HM-7.0 590 SAO code clean-up HM HM-7.0 defect closed 2012-06-26T06:59:43+02:00 2012-06-26T07:59:01+02:00 "Redudnat SAO code, such as: function never called, context model never used, variables remain from SAO APS mode needs to be removed. " dionismkim HM-7.0 593 type mistake in decoder HM HM-7.0 defect closed 2012-06-27T11:51:13+02:00 2012-08-20T00:28:23+02:00 " m_pcLoopFilter->setCfg(pcSlice->getPPS()->getDeblockingFilterControlPresent(), pcSlice->getLoopFilterDisable(), pcSlice->getLoopFilterBetaOffset(), pcSlice->getLoopFilterTcOffset(), bLFCrossTileBoundary); In the HM-7.1rc1, the second param want UInt but got Bool, In my VS2008, here UInt is not one, I got 0xEE when pcSlice->getLoopFilterDisable() return true." chenm003 HM-7.0 596 overflow in RDOQ for 14-bit coding HM HM-7.0 defect closed 2012-06-28T16:08:17+02:00 2012-07-03T01:27:28+02:00 As described in JCTVC-I0108, 14-bit coding issues were suspected. The problem (mainly) comes from RDOQ variable overflow for 14-bit coding. This has been tested and it is fixed by the proposed patch (about 4.5% coding gain for 14-bit coding that makes it consistent with 8, 10, 12 -bit coding gain). pandrivon HM-7.0 599 Long term reference pictures (LTRPs) and MSB cycle presence HM HM-7.0 defect closed 2012-07-01T03:48:17+02:00 2013-04-01T03:36:14+02:00 "There are two locations where the MSB-cycle presence is not checked for LTRPs. 1. The first location is in TComSlice.cpp::checkThatAllRefPicsAreAvailable(), line 984. Similar to the check in line 960, the presence of MSB cycle should be checked here. if((rpcPic->getPicSym()->getSlice(0)->getPOC()%(1<getPicSym()->getSlice(0)->getSPS()->getBitsForPOC())) == (this->getPOC() + pReferencePictureSet->getDeltaPOC(i))%(1<getPicSym()->getSlice(0)->getSPS()->getBitsForPOC()) && rpcPic->getSlice(0)->isReferenced()) 2. The second occurrence is also in TComSlice.cpp, in the function setRefPicList(). In line 429, the function xGetLongTermRefPic(rcListPic, m_pcRPS->getPOC(i)) is used to fetch the long-term reference picture, but again no check is made for MSB-cycle presence. NOTE: The attached patch file was created with respect to HM7.1 (r2479)" adarsh HM-7.0 645 Bit count for slice header with RPS_COUNTER HM HM-7.0 defect closed 2012-07-26T23:03:08+02:00 2012-10-08T14:30:44+02:00 "This is with respect to the HM-7.0-dev-AHG13 branch. The bits used by the RPS-related parameters int the slice header are counted using the m_bitsForSliceHeader and finally printed in TAppDecTop.cpp. Before printing, the actual number of bits is calculated by ''int shbits = (m_cTDecTop.getPPS()->getBitsForSliceHeader()+2)/2; //All slice headers except for the first intra picture are counted twice. The first intra costs 2 bits.'' The comment refers to the issue with the decoder software that the slice header is parsed twice; but this is true only for the slice header of the first slice of the picture. The slice headers of the rest of the slices are parsed only once. This is described in the comment in TAppDecTop.cpp ''/* location serves to work around a design fault in the decoder, whereby the process of reading a new slice that is the first slice of a new frame requires the TDecTop::decode() method to be called again with the same nal unit. */'' When the final bit-count is divided by two (in the above equation), it implicitly assumes that there is only one slice per each picture or all slice headers are parsed twice. This would be erroneous for cases where there are more than one slice, which is often the case when the MTU-size matching mode is enabled in the common conditions described in I0608. A solution to this problem would be to check whether the current parse of the slice header is indeed the first parse (which happens only for the first slice), and only count the bits then. The attached patch (w.r.t. r2613) provides a possible solution." adarsh HM-7.0 501 Decoding part_mode with inter_4x4 can use CNU context HM HM-7.0 enhancement closed 2012-04-24T03:18:57+02:00 2014-01-11T21:38:13+01:00 "When disable_inter_4x4 is equal to 0, it is possible to decode a bin for part_mode with context increment of 2, which indexes a context state initialized with CNU (154). This should be explicitly called out, not left up to the default catch-all. {{{ static const UChar INIT_PART_SIZE[3][NUM_PART_SIZE_CTX] = { { 184, CNU, CNU, CNU, }, { 154, 139, '''CNU''', CNU, }, { 154, 139, '''CNU''', CNU, }, }; }}} {{{ TDecSbac::parsePartSize .... for ( UInt ui = 0; ui < uiMaxNumBits; ui++ ) { // ui could be 2 at here m_pcTDecBinIf->decodeBin( uiSymbol, m_cCUPartSizeSCModel.get( 0, 0, ui) ); if ( uiSymbol ) { break; } uiMode++; } }}} " pieterkapsenberg HM-7.0 582 Removal of now unused code related to old WPP FLUSH_ALIGN HM HM-7.0 task closed 2012-06-22T11:39:16+02:00 2012-06-26T00:24:03+02:00 "Since WPP has been mandated to use one row per substream, some code can be removed from the reference software. This code, related to the old and badly named OL_FLUSH_ALIGN define, was used to perform flush operations at line boundaries *within* a substream that spanned multiple LCU lines. This is no longer useful. A patch showing the changes is attached (based on development release 2445), along with md5sums of class C & D sequences (all MAIN profiles) showing that reference, WPP and class-D-tile bitstreams are unchanged before and after the code modification. " gordon HM-6.3 532 "Can not parse ""FrameToBeEncoded"" in encoding config file correctly in HM-6.3" HM HM-6.3 defect closed 2012-05-08T06:09:12+02:00 2012-05-14T16:17:56+02:00 "In HM-6.3, TAppEncCfg.cpp, line 197, the ""FramesToBeEncoded"" should be ""FrameToBeEncoded"" (should not have a extra ""s""). " peterchuang HM-6.2 327 AMP allowed at incorrect CU depths HM HM-6.2 defect closed 2012-02-17T03:10:47+01:00 2012-06-15T22:43:21+02:00 "According to the binarization for part_mode, AMP partition modes are only possible when cLog2CbSize is greater than Log2MinCbSize. The following code from HM-5.1 fails to implement this correctly. for (Int i = 0; i < m_cSPS.getMaxCUDepth() - 1; i++) { m_cSPS.setAMPAcc( i, m_cSPS.getUseAMP() ); } The getMaxCUDepth function returns the total depth, taking into account both the minimum CU and minimum TU sizes. Therefore, depending on the minimum TU size, HM can potentially allow AMP even when cLog2CbSize = Log2MinCbSize. Also, the ""-1"" in the for loop is not necessary. " bheng HM-6.2 366 Derivation of intra luma mode predictors when neighbor is PCM coded. HM HM-6.2 defect closed 2012-03-01T02:51:05+01:00 2012-05-06T16:54:27+02:00 " In TComDataCU::getIntraDirLumaPredictor, the logic used to determine iLeftIntraDir and iAboveIntraDir directions should take into account the case where one of the neighboring CUs is PCM coded. The values in m_puhLumaIntraDir should either be initialized to ""Intra_DC"" rather than ""2"" (which no longer corresponds to DC mode), and/or there should be additional cases added to getIntraDirLumaPredictor( ) to check for PCM mode. " bheng HM-6.2 513 SAO Interleaving: Merge-up flag missing if above CU is first in the slice. HM HM-6.2 defect closed 2012-04-30T22:55:32+02:00 2012-05-15T02:07:04+02:00 "The following code prevents merge-up when the above CU is the first CU in the current slice (cuAddrUpInSlice==0). {{{ if ( (ry > 0) && (cuAddrUpInSlice>0||lfCrossSliceBoundaryFlag)) { m_pcEntropyCoderIf->codeSaoMergeUp(saoParam->saoLcuParam[compIdx][addr].mergeUpFlag); } }}} This restriction does not seem to be necessary. The attached patch fixes the problem by changing the condition to cuAddrUpInSlice>=0. " bheng HM-6.2 514 CropUnitX and CropUnitY factors are missing from picture cropping. HM HM-6.2 defect ksuehring closed 2012-04-30T23:44:41+02:00 2012-05-06T16:59:50+02:00 "The CropUnit factors (x2 for 4:2:0 chroma, etc...) are missing from the implementation of picture cropping in HM6.2rc1. The attached patch can be used to fix this issue. " bheng HM-6.2 515 QP adaptation fails when minimum transform size is not 4x4 HM HM-6.2 defect closed 2012-05-01T00:05:00+02:00 2012-06-26T01:13:28+02:00 "The number of partitions in the delta-QP region width, as calculated below, is only correct when the partition width is 4 pixels. This is only true if the minimum transform size is 4x4. UInt uiNumPartInQpMinCUWidth = getSlice()->getPPS()->getMinCuDQPSize()>>2; The attached patch can be used to fix this issue. " bheng HM-6.2 516 Setting weighted_bipred_idc=0 disables weighted prediction in P-slices. HM HM-6.2 defect closed 2012-05-01T01:28:23+02:00 2012-05-06T17:08:02+02:00 "The function xPredInterBi( ) is called for both P- and B-slices. In this function, only the value of weighted_bipred_idc is used. So, when coding a P-slice, the value of weighted_pred_flag if ignored, and setting weighted_bipred_idc=0 will incorrectly disable weighted prediction. I believe the attached patch could be used to fix the issue. " bheng HM-6.2 534 variable initialization HM HM-6.2 defect closed 2012-05-12T01:34:20+02:00 2012-05-21T13:54:36+02:00 "In processSaoUnitAll(), the variable {{{ static Int offset[LUMA_GROUP_NUM+1]; }}} should be initialized to zero " chihming.fu HM-6.1 497 Memory Leaks in HM-6.1 decoder HM HM-6.1 defect closed 2012-04-20T17:52:25+02:00 2012-04-20T19:34:12+02:00 "Hi, We have observed significant memory leak issues in the HM-6.1 decoder. I am attaching a valgrind report. Could you coordinate with other experts and have them addressed appropriately? Regards, Adeel " adeel@… HM-6.1 499 Decoding transform subdiv flag at depth 0 uses CNU context HM HM-6.1 defect closed 2012-04-23T19:26:18+02:00 2014-01-13T00:56:27+01:00 "In a stream with 32x32 LCUs, it is possible to call the function TDecSbac::parseTransformSubdivFlag with a depth of 0. The context selection is done with this depth, and in HM right now this context is not used, so the bistream gets coded and decoded with the dummy init value of 154: static const UChar INIT_TRANS_SUBDIV_FLAG[3][NUM_TRANS_SUBDIV_FLAG_CTX] = { { '''CNU''', 224, 167, 122, CNU, CNU, CNU, CNU, CNU, CNU, }, { '''CNU''', 124, 138, 94, CNU, CNU, CNU, CNU, CNU, CNU, }, { '''CNU''', 153, 138, 138, CNU, CNU, CNU, CNU, CNU, CNU, }, }; Incidentally, the parameter name uiLog2TransformBlockSize of the TDecSbac::parseTransformSubdivFlag function should really be called uiDepth, since that is what it used for." pieterkapsenberg HM-6.1 460 text mismatch in check wether log2TrafoSize == Log2MinTrafoSize HM HM-6.1 defect closed 2012-04-03T16:13:11+02:00 2012-04-27T19:33:30+02:00 "The TU processing and the chroma cbf parsing in the draft is conditioned on log2TrafoSize==Log2MinTrafoSize whereas in HM it is conditioned on log2TrafoSize==2, as in e.g. DecEntropy.cpp l.623 (DecEntropy::xDecodeTransform): if( uiLog2TrafoSize > 2 ) ... else ... Thus, instances where a log transform size is compared to 2 should be replaced with a comparison to the min log transform size. Furthermore to ensure that this is working the bitstream shall not contain data that result in Log2MinTrafoSize >= Log2MinCbSize. (see http://hevc.kw.bbc.co.uk/trac/ticket/459) This is taken care of by the encoder cfg but it should be considered at the decoder as well. Note that this does not affect the common test conditions." bbross HM-6.1 468 Memory leak in HM6.1 decoder HM HM-6.1 defect closed 2012-04-05T11:01:17+02:00 2012-04-20T19:34:13+02:00 "Only class D test sequences can be decoded with a 32-bit decoder, due to a memory leak. The leak seems to occur in TDecTop::xGetNewPicBuffer, where an rpcPic->create() occurs at the end of the method. This does not delete any existing buffers in the rpcPic prior to creating new ones. Inserting: rpcPic->destroy(); prior to the create() solves the problem. " gordon HM-6.1 472 Lossless mode integration in deblocking filter HM HM-6.1 defect closed 2012-04-06T19:29:00+02:00 2014-01-13T00:52:24+01:00 "In HM6.1, the deblocking filter will disable filtering for the left and top boundaries of a losslessly coded block, while still filtering the bottom and right edges. It is suggested to replace the following code in HM functions xEdgeFilterLuma and xEdgeFilterChroma: {{{ ""#if LOSSLESS_CODING // check if each of PUs is lossless coded bPartPNoFilter = bPartPNoFilter || (pcCU->isLosslessCoded(uiAbsZorderIdx) ); bPartQNoFilter = bPartQNoFilter || (pcCU->isLosslessCoded(uiAbsZorderIdx) ); #endif "" with ""#if LOSSLESS_CODING // check if each of PUs is lossless coded bPartPNoFilter = bPartPNoFilter || (pcCUP->isLosslessCoded(uiPartPIdx) ); bPartQNoFilter = bPartQNoFilter || (pcCUQ->isLosslessCoded(uiPartQIdx) ); #endif. "" }}}" geertv HM-6.1 474 Missing initialization of I_PCM transform index HM HM-6.1 defect closed 2012-04-09T06:43:43+02:00 2012-04-28T15:43:27+02:00 "When I_PCM is selected, its transform index is not initialized at decoder. Although tranform index is not used in I_PCM encoding and decoding, the value should be initialized (with 0). Attachment is a patch to HM-6.1-dev rev.2173. (Note that the patch also includes the initialization at encoder to ensure it in future modifications in the related codes.) The patch does not affect results under common test conditions with I_PCM as long as QPs of I_PCM regions are set to 0 during deblocking process. " kchono HM-6.1 475 Text/HM mismatch in alf_nb_pred_luma_flag HM HM-6.1 defect closed 2012-04-09T12:25:44+02:00 2012-11-30T04:43:12+01:00 In HM-6.0 and HM-6.1 software, the (N-1)th coefficient of luma ALF filter is predicted from other coefficients when alf_nb_pred_luma_flag == 0. However, in the WD6_dK text (subclause 8.7.3.2.1), the prediction is done when alf_nb_pred_luma_flag == 1. It is suggested to modify the HM software to align with the WD6_dK text. yamakage HM-6.1 490 Redundant RBSP trailing bits at the end of slice HM HM-6.1 defect closed 2012-04-15T23:20:58+02:00 2014-01-13T00:50:32+01:00 "In HM-6.1, all substreams are byte-aligned by inserting RBSP trailing bits at the end. However, there is another call to insert RBSP trailing bits after all substreams are added to the main stream. The final addition of RBSP trailing bits in redundant and unnecessary. According to the specification, there should be only one instance of RBSP trailing bits insertion at the end of a tile/wavefront if that also happens to be the end of the slice as well. I think the mitigation can be simply achieved by commenting/removing the following statement at line 1186 in compressGOP() function. writeRBSPTrailingBits(nalu.m_Bitstream);" sandeepkanumuri HM-6.1 495 Mismatch between HM and CD in ALF filter output calculation HM HM-6.1 defect closed 2012-04-19T18:32:03+02:00 2012-06-26T01:58:07+02:00 "There is a mismatch between HM and CD in ALF filter output calculation as a result of integration of H0068. The existing HM code will transmit ALF coefficients in the order: C0, C1, C4, C3, C2, C5, C6, C7, C8, C9 instead of the ""natural"" order of: C0, C1, C2, C3, C4, C5, C6, C7, C8, C9. The fixed code does not result in any BD-Rate difference since only the order of transmission of coeffs is different, but it will result in a different bitstream. Patch on top of HM-6.0 and BD-Rate results attached " madhukar HM-6.1 498 Encoder can create invalid bitstream if Frame0 has non-zero temporal_id HM HM-6.1 defect closed 2012-04-21T22:43:30+02:00 2012-04-28T20:28:04+02:00 The RPS generation process requires Frame1 to have temporal_id equal to zero so that when inserting an intra period (with automatically set temporal_id value) the repeating reference structure stays the same. ksuehring HM-6.1 503 encoder crash when ASR is enabled HM HM-6.1 defect closed 2012-04-25T16:32:22+02:00 2012-05-05T17:16:04+02:00 "The encoder crashes when ASR=1 is set. It seems the ASR code does not properly handle the combined list related changes." ksuehring HM-6.1 507 POC cycle not taken into account for long-term reference pictures HM HM-6.1 defect closed 2012-04-28T18:17:59+02:00 2012-04-28T18:20:38+02:00 checkThatAllRefPicsAreAvailable() and applyReferencePictureSet() do not use the POC cycle to mark long-term reference pictures ksuehring HM-6.1 511 mismatch between the WD text and the HM software in slice header on entropy_slice_flag, ref_pic_list_combiation() and mvd_l1_zero_flag HM HM-6.1 defect closed 2012-04-30T10:20:25+02:00 2012-08-17T22:42:45+02:00 "In the text, ref_pic_list_combination() and mvd_l1_zero_flag in slice header are conditioned on entroy_slice_flag. But they are coded/decoded regardless of entropy_slice_flag in the HM software. The part of ref_pic_list_combiation() and mvd_l1_zero_flag in slice header should be moved into the ""if(!bEntropySlice){}"" bracket for parseSliceHeader() in TDecCAVAL.cpp and codeSliceHearder() in TEncCavlc.cpp. Possible solution: codeSliceHeader() in TEncCavlc.cpp ...... if(!bEntropySlice) { WRITE_UVLC( pcSlice->getPPS()->getPPSId(), ""pic_parameter_set_id"" ); ...... //<< move the part of ref_pic_list_combiation() and mvd_l1_zero_flag in slice header here!!! : start if (pcSlice->isInterB()) { WRITE_FLAG(pcSlice->getRefPicListCombinationFlag() ? 1 : 0, ""ref_pic_list_combination_flag"" ); ..... #if H0111_MVD_L1_ZERO if (pcSlice->isInterB()) { WRITE_FLAG( pcSlice->getMvdL1ZeroFlag() ? 1 : 0, ""mvd_l1_zero_flag""); } #endif //>> move the part of ref_pic_list_combiation() and mvd_l1_zero_flag in slice header here!!! : end #if H0412_REF_PIC_LIST_RESTRICTION } #endif parseSliceHeader() in TDecSbac.cpp ...... if (!bEntropySlice) { READ_UVLC ( uiCode, ""pic_parameter_set_id"" ); rpcSlice->setPPSId(uiCode); ...... //>> move the part of ref_pic_list_combiation() and mvd_l1_zero_flag in slice header here!!! : start if (rpcSlice->isInterB()) { READ_FLAG( uiCode, ""ref_pic_list_combination_flag"" ); rpcSlice->setRefPicListCombinationFlag( uiCode ? 1 : 0 ); .... #if H0111_MVD_L1_ZERO if (rpcSlice->isInterB()) { READ_FLAG( uiCode, ""mvd_l1_zero_flag"" ); rpcSlice->setMvdL1ZeroFlag( (uiCode ? true : false) ); } #endif //>> move the part of ref_pic_list_combiation() and mvd_l1_zero_flag in slice header here!!! : end } else { pps = rpcSlice->getPPS(); sps = rpcSlice->getSPS(); } " suzukiyos HM-6.1 520 Derivation of iNumRowTilesMinus1 appears to be wrong (TDecCAVLC.cpp) HM HM-6.1 defect ksuehring closed 2012-05-03T14:02:22+02:00 2012-05-06T20:09:09+02:00 "In HM-6.1, on line 1269 of TDecCAVLC.cpp, the derivation of iNumRowTilesMinus1 appears to be wrong. Int iNumRowTilesMinus1 = (pcPPS->getColumnRowInfoPresent() == 1)?(pcPPS->getNumColumnsMinus1()):(pcPPS->getSPS()->getNumRowsMinus1()); Is it correct to derive iNumRowTilesMinus1 from pcPPS->getNumColumnsMinus1()?" sandeepkanumuri HM-6.1 487 Possible typo in a comment HM HM-6.1 defect closed 2012-04-13T16:27:31+02:00 2012-06-26T01:40:15+02:00 "In TComDataCU.cpp in HM6.1 and in earlier versions, near lines 4404 and 4426, there's a comment ""//if multiple scans supported for PU size"". Should ""PU"" be changed to ""TU"" in those comments, given that the decision on scan type is based upon the transform size? " cohen HM-6.0rc1 379 Config files for new class E sequences not provided HM HM-6.0rc1 defect closed 2012-03-05T10:56:49+01:00 2012-03-05T15:29:02+01:00 Config files for the new class E sequences are not present in the cfg directory while those for vidyo{1,3,4} are. thomasd HM-6.0rc1 420 NAL losses causes the decoder to crash HM HM-6.0rc1 enhancement closed 2012-03-20T15:38:55+01:00 2012-03-21T16:47:31+01:00 The HM decoder crashes for bitstreams where coded slice NAL units containing are missing. rickard HM-6.0 392 enc-dec mismatch occurs when QP_adaptation enabled HM HM-6.0 defect closed 2012-03-08T07:07:40+01:00 2014-10-15T17:45:47+02:00 "Enc-dec mismatch occurs if MaxCuDQPDepth is set to 1 and encoder config option ""-aq 1 -aqr 12"" is specified." kazushi HM-6.0 397 enc-dec mismatch occurs when QP_adaptation enabled and LCUSize=32 HM HM-6.0 defect closed 2012-03-09T10:22:25+01:00 2012-08-20T01:18:10+02:00 "enc-dec mismatch occurs if parameters in config are set as MaxCUWidth 32 MaxCUHeight 32 MaxPartitionDepth 3 MaxCuDQPDepth 1 and command options ""-aq 1 -aqr 12"" are specified. (It does not occur if these options are not set even with the config setting above.) " kazushi HM-6.0 381 xParseSaoUnit() style issues HM HM-6.0 defect closed 2012-03-05T15:30:14+01:00 2012-08-20T00:51:49+02:00 "xParseSaoUnit() uses xReadCode() instead of proper TRACE support variables uiLength and ruiVal do not match coding style" ksuehring HM-6.0 387 Decoder crash when entropy slices and SAO are enabled HM HM-6.0 defect closed 2012-03-06T20:05:47+01:00 2012-03-09T10:23:27+01:00 The HM-6.0rc1 decoder crashes when the entropy slice is enabled. shilin.xu HM-6.0 389 Text / HM mismatch for slice_type HM HM-6.0 defect closed 2012-03-07T02:18:40+01:00 2012-05-13T19:50:10+02:00 "Text defines: slice_type = 0 for P slice slice_type = 1 for B slice slice_type = 2 for I slice HM defines: slice_type = 0 for I slice slice_type = 1 for P slice slice_type = 2 for B slice The numbering scheme in the text is aligned with prior AVC specification. It is therefore suggested to modify the SW to align it with the text. " fbossen HM-6.0 390 """Derivation process for luma intra prediction mode"" mistake between HM and Document" HM HM-6.0 defect closed 2012-03-07T10:39:35+01:00 2012-03-07T14:58:24+01:00 "In the function getIntraDirLumaPredictor(), we can look some code below: uiIntraDirPred[0] = iLeftIntraDir; uiIntraDirPred[1] = ((iLeftIntraDir + 29) % 32) + 2; uiIntraDirPred[2] = ((iLeftIntraDir - 1 ) % 32) + 2; But in the Document(H1003-v21): candModeList[0] = candIntraPredModeA (8-24) candModeList[1] = 2 + ( ( candIntraPredModeA − 2 − 1 ) % 32 (8-25) candModeList[2] = 2 + ( ( candIntraPredModeA − 2 + 1 ) % 32 (8-26) It looks HM-6.0 don't match to (8-25) and (8-26). " chenm003 HM-6.0 393 Encoder crashes when allowing only 4x4 trafo size HM HM-6.0 defect closed 2012-03-08T17:40:13+01:00 2014-01-13T01:15:43+01:00 "The encoder crashes when encoding the first B or P picture if it is configured such that only 4x4 transform size is allowed, i.e. by using the following configuration parameters: QuadtreeTULog2MaxSize : 2 QuadtreeTULog2MinSize : 2 QuadtreeTUMaxDepthInter : 1 QuadtreeTUMaxDepthIntra : 1 " winken HM-6.0 395 on the usage of iCombinedCount HM HM-6.0 defect closed 2012-03-09T05:59:17+01:00 2014-01-12T02:42:33+01:00 "In HM-6.1-dev r2096, the combined merge candidates are generated according to the following process. Int iCombinedCount = 0; ... for (Int idx=0; idxparseTransformSubdivFlag( uiSubdiv, uiDepth ); }}} The corresponding bitstreams are attached. This can easily be fixed by removing '- SplitFlag' in l.2055 in TComDataCU::getQuadtreeTULog2MinSizeInCU( UInt uiIdx ): {{{ uiLog2MinTUSizeInCU = m_pcSlice->getSPS()->getQuadtreeTULog2MaxSize(); }}} After the fix is applied, the subdivision flag is not signaled anymore and the mismatch is gone and in config 2.a the case of a 64x64 CB with non-2Nx2N inter partitions is not encoded (chosen) anymore 2.b the case of a 64x64 CB with non-2Nx2N inter partitions is chosen but no subdivision flag signaled anymore. After I decrypted what the function TComDataCU::getQuadtreeTULog2MinSizeInCU( UInt uiIdx ) is doing, especially w.r.t to draft text, I took the chance to clean the function up. The cleanup patch (bit exact) and the cleanup patch including the fix are attached. The fixed code matches with draft text. Another observation in the code is that TComDataCU::getQuadtreeTULog2MinSizeInCU( UInt uiIdx ) only depends on the CU address AbsPartIdx/uiIdx and does not change during recursive call of TDecEntropy::xDecodeTransform/TDecEntropy::xDecodeTransformSubdiv. This function can be taken out of the recursion and passed, e.g. as a parameter uiLog2MinTUSizeInCU so that multiple calls of the function leading to the same result can be avoided." bbross HM-6.0 421 Not possible to encode sequences shorter than 2 x GOPSize HM HM-6.0 defect closed 2012-03-20T15:50:24+01:00 2012-03-21T16:48:03+01:00 In the encoder there is a restriction that FrameToBeEncoded must be at least 2 x GOPsize. This prohibits encoding of short sequences with long GOPs (e.g. a sequence consisting of a single GOP). jonatan HM-6.0 422 QP adaptation fails when max CU size is not 64x64 HM HM-6.0 defect closed 2012-03-21T02:59:25+01:00 2012-03-21T16:21:39+01:00 "The current implementation of QP adaptation makes the assumption that there are always 256 partitions in each LCU and that each partition is size 4x4. However, these assumptions are only true when the maximum CU size is 64x64 and the minimum TU size is 4x4. The code currently fails to work correctly when the max/min CU sizes or TU sizes are set to some other values. For example, the following functions contain such issues: - parseDeltaQP( ) - getQpMinCuLeft( ) - getQpMinCuAbove( ) - getLastCodedQP( ) {{{ UInt uiAbsQpCUPartIdx = (uiAbsPartIdx>>(8-(pcCU->getSlice()->getPPS()->getMaxCuDQPDepth()<<1)))<<(8-(pcCU->getSlice()->getPPS()->getMaxCuDQPDepth()<<1)) ; UInt uiAbsRorderQpMinCUIdx = g_auiZscanToRaster[(uiCurrAbsIdxInLCU>>(8-(getSlice()->getPPS()->getMaxCuDQPDepth()<<1)))<<(8-(getSlice()->getPPS()->getMaxCuDQPDepth()<<1))]; UInt uiAbsZorderQpMinCUIdx = (uiCurrAbsIdxInLCU>>(8-(getSlice()->getPPS()->getMaxCuDQPDepth()<<1)))<<(8-(getSlice()->getPPS()->getMaxCuDQPDepth()<<1)); UInt uiNumPartInQpMinCUWidth = getSlice()->getPPS()->getMinCuDQPSize()>>2; UInt uiQUPartIdxMask = ~((1<<(8-(getSlice()->getPPS()->getMaxCuDQPDepth()<<1)))-1); }}} " bheng HM-6.0 425 m_iNumColumnsMinus1 and m_iNumRowsMinus1 uninitialed, decoder will crash in debug mode HM HM-6.0 defect closed 2012-03-22T11:54:41+01:00 2012-03-22T13:50:11+01:00 "Both m_iNumColumnsMinus1 and m_iNumRowsMinus1 in SPS are uninitialed. The decoder will crash in xDecodeSlice() when someone debug code;" chenm003 HM-6.0 426 order of tile related SPS syntax elements HM HM-6.0 defect closed 2012-03-22T12:40:37+01:00 2012-03-22T12:58:12+01:00 The location of uniform_spacing_flag in the software does not match the draft. ksuehring HM-6.0 427 uniform_spacing_flag related code needs to be cleaned up HM HM-6.0 defect closed 2012-03-22T12:56:59+01:00 2012-08-20T01:20:55+02:00 uniform_spacing_flag is represented in the code using the term UniformSpacingIdr. This should be changed to a boolean flag to match the text. ksuehring HM-6.0 429 Encoder creates a different bitstream each time when using wavefront option with 2 substreams HM HM-6.0 defect closed 2012-03-22T19:26:38+01:00 2012-03-23T12:06:05+01:00 "In HM-6.0-dev branch, if we use wavefronts with 2 substreams, the encoder creates a slightly different bitstream each time it is run. I run the encoder with the following options: Release\TAppEncoder.exe -c encoder_lowdelay_main.cfg -c RaceHorses.cfg --FrameToBeEncoded=8 --WaveFrontSynchro=1 --WaveFrontFlush=1 --WaveFrontSubstreams=2 The config files used are attached (should be the same as those in software). However, if I change WaveFrontSubstreams to 4, I don't see this issue (the bitstream generated does not change with each run). As far as I can tell, this issue starts with revision 2120." sandeepkanumuri HM-6.0 430 SliceMode = 2 bug HM HM-6.0 defect closed 2012-03-22T22:24:53+01:00 2012-03-27T14:19:20+02:00 "When sliceMode = 2, the encoder seems to encode the last LCU of a tile for multiple times to achieve the bytes limit. This will result in two issues: 1) multiple slices are generated at the position of the last LCU of a tile. 2) the encoder runs much slower than normal. I suspect this issue is related to the code associated with ""COMPLETE_SLICES_IN_TILE"" macro." shilin.xu HM-6.0 436 context initValue undefined for split_transform_flag when depth is equal to zero HM HM-6.0 defect closed 2012-03-23T22:19:03+01:00 2014-01-11T21:20:53+01:00 "In HM 6.0, split_transform_flag uses a depth-based context initValue table as follows: {{{ #!python INIT_TRANS_SUBDIV_FLAG[3][NUM_TRANS_SUBDIV_FLAG_CTX] = { { CNU, 224, 167, 122, CNU, CNU, CNU, CNU, CNU, CNU, }, { CNU, 124, 138, 94, CNU, CNU, CNU, CNU, CNU, CNU, }, { CNU, 153, 138, 138, CNU, CNU, CNU, CNU, CNU, CNU, }, }; }}} The context initValue for depth zero is equal to CNU (context model not used). This is true when LCU size is 64x64 since the split_transform_flag is never coded for depth zero. But when LCU size is less than 64x64, e.g., 16x16, split_transform_size may be coded for depth zero and the context initValue is undefined. Besides that, the context initValue in the spec (Table 9-23) has not been updated yet. " zhyang HM-6.0 438 Text / HM mismatch for NAL unit header syntax HM HM-6.0 defect closed 2012-03-26T16:53:22+02:00 2012-03-28T14:17:59+02:00 "According to JCTVC-H1003_dK section 7.3.1, the first byte of the NAL unit is: forbidden_zero_bit : 1 bit nal_ref_flag : 1 bit nal_unit_type : 6 bits But the format written by the encoder (source/Lib/TLibEncoder/NALwrite.cpp) is: forbidden_zero_flag : 1 bit nal_ref_idc : 2 bits nal_unit_type : 5 bits " Smarter HM-6.0 439 Initialization of m_bLMvdL1Zero HM HM-6.0 defect closed 2012-03-27T09:11:59+02:00 2012-03-28T16:08:20+02:00 In HM 6.0 when using slices, the TComSlice variable m_bLMvdL1Zero is never initialized except for the first slice in each picture. rickard HM-6.0 440 Text / HM mismatch: NAL_UNIT_APS has incorrect value HM HM-6.0 defect closed 2012-03-27T14:05:37+02:00 2012-03-27T15:36:31+02:00 According to JCTVC-H1003_dK, APS has nal_unit_type 14, but in source/Lib/TLibCommon/CommonDef.h, NAL_UNIT_APS has value 13 in the NalUnitType enum. Smarter HM-6.0 444 Lambda modifier is only initialised for layer 0 to 3 HM HM-6.0 defect closed 2012-03-29T12:26:01+02:00 2012-11-30T04:53:02+01:00 "A lambda modifier is defined for each layer in the GOP hierarchy. Only layers 0 to 3 are initialised in class TAppEncCfg although it's possible to use up to layer 7. Moreover, there is no mechanism to set the lambda modifier for those lower layers of the GOP hierarchy. The attached patch remedies both problems but doesn't address the issue that the size of the array of lambda modifiers is defined elsewhere (macro MAX_TLAYER in CommonDef.h). I think we can live with that." mindthegab HM-6.0 447 parameter set extension flags missing HM HM-6.0 defect closed 2012-03-29T16:27:36+02:00 2012-03-29T16:28:51+02:00 SPS, PPS and APS extension flags are not implemented in HM 6.0 ksuehring HM-6.0 449 APS writing needs cleanup HM HM-6.0 defect closed 2012-03-29T16:35:00+02:00 2012-08-20T00:39:32+02:00 "Since there is no CABAC coding in the APS, the APS writing functions should be cleaned up similar to the decoder, i.e. moving all decision logic to the VLC writer similar to SPS and PPS. r2158 shows a good example how complicated it is to add a single bit at the end of the APS compared to SPS or PPS. Also only few of the APS fields support trace file functionality at the encoder." ksuehring HM-6.0 450 context initValue undefined for the third context of Part Size in P and B slices HM HM-6.0 defect closed 2012-03-30T03:19:31+02:00 2014-01-13T00:33:05+01:00 "in HM 6.0, the third context for PartSize is labeled as not used. INIT_PART_SIZE[3][NUM_PART_SIZE_CTX] = { { 184, CNU, CNU, CNU, }, { 154, 139, CNU, CNU, }, { 154, 139, CNU, CNU, }, }; In some uncommon test conditions (e.g., DisableInter4x4 = 0), the third context in P and B slices will be used. It is suggested replacing CNU with 154. INIT_PART_SIZE[3][NUM_PART_SIZE_CTX] = { { 184, CNU, CNU, CNU, }, { 154, 139, 154, CNU, }, { 154, 139, 154, CNU, }, }; Patch file for this fix (based on rev 2162) is attached. (file name ""ctx_init_value_for_partsize.patch"")" liweig HM-6.0 453 PPS: entropy_coding_mode_flag draft/software mismatch HM HM-6.0 defect closed 2012-03-30T13:06:33+02:00 2012-05-06T19:59:04+02:00 "The HM software still contains entropy_coding_mode_flag which does not exist in the draft: {{{ WRITE_FLAG( pcPPS->getEntropyCodingMode() ? 1 : 0, ""entropy_coding_mode_flag"" ); }}} " ksuehring HM-6.0 454 PPS: num_ref_idx_lX_default_active_minus1 draft/software mismatch HM HM-6.0 defect closed 2012-03-30T13:08:28+02:00 2012-04-21T20:50:17+02:00 "The following PPS syntax elements are missing the the HM software: num_ref_idx_l0_default_active_minus1 ue(v) num_ref_idx_l1_default_active_minus1 ue(v) " ksuehring HM-6.0 455 SPS: VUI not implemented HM HM-6.0 defect closed 2012-03-30T14:23:14+02:00 2012-09-28T21:29:35+02:00 "VUI syntax and switching flag are not implemented in the HM software vui_parameters_present_flag u(1) if( vui_parameters_present_flag ) vui_parameters( ) " ksuehring HM-6.0 456 Slice header: SAO and ALF flag positions wrong HM HM-6.0 defect closed 2012-03-30T15:21:19+02:00 2012-08-20T00:50:00+02:00 The positions / conditions of SAO and ALF flags in the slice header does not match the draft: slice_adaptive_loop_filter_flag, slice_sao_interleaving_flag, etc. ksuehring HM-6.0 457 Potential Bug in HM6.0 HM HM-6.0 defect tung.nguyen closed 2012-04-01T13:04:52+02:00 2012-04-02T15:18:41+02:00 "When we did expeiments on HM4.0, we observed that the following section of the code of the function ""encodeCoeff ""in the file ""TEncEntropy.cpp"" does not seem to behave in the correct way. if ( !pcCU->getQtRootCbf( uiAbsPartIdx ) ) { return; } It seems that the above code should be modified as follows. if ( !pcCU->getQtRootCbf( uiAbsPartIdx ) ) { pcCU->setCbfSubParts( 0, 0, 0, uiAbsPartIdx, uiDepth ); pcCU->setTrIdxSubParts( 0 , uiAbsPartIdx, uiDepth ); return; } In this way, it can also match the following section of the code of the function ""decodeCoeff"" in the file ""TDecEntropy.cpp"" if ( !uiQtRootCbf ) { pcCU->setCbfSubParts( 0, 0, 0, uiAbsPartIdx, uiDepth ); pcCU->setTrIdxSubParts( 0 , uiAbsPartIdx, uiDepth ); return; } The following section of the code of the function ""encodeCoeff "" in the file ""TEncEntropy.cpp"" of HM6.0 also has the same problem. if ( !pcCU->getQtRootCbf( uiAbsPartIdx ) ) { #if NSQT_LFFIX pcCU->setNSQTIdxSubParts( uiAbsPartIdx, uiDepth ); #endif return; } It seems that it should make the following changes. if ( !pcCU->getQtRootCbf( uiAbsPartIdx ) ) { pcCU->setCbfSubParts( 0, 0, 0, uiAbsPartIdx, uiDepth ); pcCU->setTrIdxSubParts( 0 , uiAbsPartIdx, uiDepth ); #if NSQT_LFFIX pcCU->setNSQTIdxSubParts( uiAbsPartIdx, uiDepth ); #endif return; } " NaZhang HM-6.0 502 HM Encoder crash with divide by 0 error in deblocking for min transform size = 32 HM HM-6.0 defect closed 2012-04-25T00:45:52+02:00 2014-01-13T01:19:37+01:00 " if ( (iEdge % ( (DEBLOCK_SMALLEST_BLOCK<<1)/uiPelsInPart ) ) == 0 ) ----------- Above line in TComLoopFilter.cpp has divide by 0 error for following settings in config file ----------- MaxCUWidth : 64 # Maximum coding unit width in pixel MaxCUHeight : 64 # Maximum coding unit height in pixel MaxPartitionDepth : 1 # Maximum coding unit depth QuadtreeTULog2MaxSize : 5 # Log2 of maximum transform size for # quadtree-based TU coding (2...6) QuadtreeTULog2MinSize : 5 # Log2 of minimum transform size for # quadtree-based TU coding (2...6) QuadtreeTUMaxDepthInter : 1 QuadtreeTUMaxDepthIntra : 1 ------------ " kumarsanjeev123 HM-6.0 531 TComSampleAdaptiveOffset::m_uiSaoBitIncrease incorectly computed for bitDepth > 8 HM HM-6.0 defect closed 2012-05-07T22:24:33+02:00 2012-11-30T05:02:52+01:00 "I looks like the following lines (1456 to 1462 in TComSampleAdaptiveOffset.cpp) fell victim to some erroneous search/replace. #if FULL_NBIT m_uiSaoBitIncrease = g_uiBitDepth + (g_uiBitDepth-8) - min((Int)(g_uiBitDepth + (g_uiBitDepth-8)), 10); #else m_uiSaoBitIncrease = g_uiBitDepth + g_uiBitIncrement - min((Int)(g_uiBitDepth + g_uiBitIncrement), 10); #endif The problem appears fixed if they are changed to just: m_uiSaoBitIncrease = g_uiBitDepth + g_uiBitIncrement - min((Int)(g_uiBitDepth + g_uiBitIncrement), 10); " ksebov HM-6.0 382 SAO: interpretation of array dimensions is overloaded HM HM-6.0 enhancement closed 2012-03-05T15:41:27+01:00 2014-01-11T21:24:25+01:00 "Various arrays are allocated based upon {{{m_iNumTotalParts}}}, derived from {{{m_aiNumCulPartsLevel[m_uiMaxSplitLevel]}}}: - m_iCount - m_iOffset - m_iOffsetOrg - m_iRate - m_iDist - m_dCost - m_iDistOrg - m_dCostPartBest - m_iTypePartBest The two definitions are effectively: - m_iCount[numTotalParts] - m_iCount[numComponents] r2080 fixes the case where numTotalParts < numComponents. In general, this sort of overloading should be fixed." davidf HM-6.0 394 New slice mode added on the top of HM-6.0rc1 HM HM-6.0 enhancement closed 2012-03-09T01:08:41+01:00 2012-03-22T15:25:34+01:00 " AHG4 on High-level parallelism has as a mandate: ""Introduce slice-tile constraint functionality into the HM (i.e., addition of a slice mode to encode slices using an integer number of tiles)."" The attached patch includes a new slice mode for HM-6.0rc1 to encode slices using an integer number of tiles." shilin.xu HM-6.0 398 Text / HM mismatch for derivation of TMVP in AMVP of HM-6.0rc1 HM HM-6.0 enhancement closed 2012-03-10T05:02:22+01:00 2015-08-24T16:27:32+02:00 "As described in section 8.5.2.1.5, the 2nd step of the ordered steps of deriving the motion vector predictor mvpLX: If both availableFlagLXA and availableFlagLXB are equal to 1 and mvLXA is not equal to mvLXB, availableFlagLXCol is set equal to 0, otherwise, the derivation process for temporal luma motion vector prediction in subclause 5 is invoked with luma location ( xP, yP ). It seems that we should append a checking before deriving the TMVP candidate in the function ""fillMvpCand"" of the file ""TComDataCU.cpp"" of HM6.0-rc1 as follows: if (pInfo->iN < AMVP_MAX_NUM_CANDS) { if ( getSlice()->getPPS()->getEnableTMVPFlag() ) { ........ } } In this way, we can eliminate the unnecessary burden of deriving TMVP. After deriving the TMVP candidate, we can delete the following statement, because it is impossible to satisfy the judgment. if (pInfo->iN > AMVP_MAX_NUM_CANDS) { pInfo->iN = AMVP_MAX_NUM_CANDS; } " NaZhang HM-6.0 399 AMVP spatial scaling candidate in HM-6.0rc1 HM HM-6.0 enhancement closed 2012-03-10T05:04:12+01:00 2014-01-13T00:22:28+01:00 "As we all know, to remove the dependency of deriving the spatial candidate of upper position on left position, the simplification 2 of JCTVC-G542 defines a new derivation way of the parameter isScaledFlagLX and be adopted in the 7th meeting. However, in the function ""fillMvpCand"" of the file ""TComDataCU.cpp"" of HM6.0-rc1, before the scaling calculation for upper position, there are two statements: bAdded = bAddedSmvp; if (pInfo->iN==2) bAdded = true; In my opinion, the 2nd statement can be deleted, as we only can derive the value of pInfo->iN after checking all the left positions. As a result, we did not really eliminate the dependencies between derivation of the spatial candidate of upper position and left position. After we carry out this modification, the experiment results is not affected, as the 2nd statement has no substantive role, whereas we really eliminate the dependency." NaZhang HM-6.0 401 DeblockingFilterControlPresent parameter misleading HM HM-6.0 enhancement karlsharman closed 2012-03-13T11:18:18+01:00 2015-03-25T20:55:00+01:00 "I think the DeblockingFilterControlPresent parameter is rather confusing at the encoder. I think the value of deblocking_filter_control_present_flag should automatically be determined based on the deblocking filter control parameters, i.e. if one of them has a non-default value this value should be included in the bitstream. For instance for disabling the deblocking filter the user will currently have to set DeblockingFilterControlPresent=1 AND LoopFilterDisable=1 which is not very intuitive. There is also no documentation on these parameters on the command line help and only outdated information in the software manual." ksuehring HM-6.0 411 Code cleanup : remove unnecessary prediction mode MODE_SKIP HM HM-6.0 enhancement SimonO closed 2012-03-15T14:54:16+01:00 2012-04-23T16:29:59+02:00 I suggest to remove the prediction mode MODE_SKIP which is not necessary anymore and which can lead to some misunderstanding in the code review. Only few lines have to be changed and this cleanup reduces the code of couple of lines. After this change, only 2 prediction modes exist: MODE_INTER and MODE_INTRA. SimonO HM-6.0 489 assert() for scalingListType HM HM-6.0 enhancement closed 2012-04-15T23:04:41+02:00 2014-01-11T21:02:35+01:00 "In several places in HM-6.0 and maybe other versions, the statement ""assert(scalingListType < 6)"" appears several times in TComTrQuant.cpp, TDecCU.cpp, and TEncSearch.cpp. Would it be better to change it to: assert(scalingListType < SCALING_LIST_NUM) ? " cohen HM-6.0 414 parameter name mismatch HM HM-6.0 defect closed 2012-03-16T11:55:13+01:00 2012-05-06T17:43:18+02:00 "In HM software there are parameters ""Chroma_QP_Offset"" and ""Chroma_QP_Offset_2nd"" but they should comply with the CD text as ""cb_qp_offset"" and ""cr_qp_offset""." kazushi HM-5.2 334 --MRG=0 breaks in HE configs HM HM-5.2 defect ksuehring closed 2012-02-21T14:24:16+01:00 2012-03-06T16:53:30+01:00 --MRG=0 causes the encoder to fail in HE configs. Since the HM introduces a flag into the SPS which is not present in the WD, it's probably best to remove this option and the SPS coding. A patch to do this is attached. thomasd HM-5.2 335 A bug in HM5.2 when using --PAD and FrameSkip together HM HM-5.2 defect ksuehring closed 2012-02-21T21:33:18+01:00 2012-03-29T16:47:04+02:00 "The HM code (the latest version in the trunk) has an issue related to frame skipping with padding. When the input video size is not the multiple of 16 we enable the --PAD option. If at the same time we set the FrameSkip parameter to a non-zero value, it will cause a wrong framesize computation for skipping. The skip function uses m_iSourceWidth and m_iSourceHeight which are the values after padding. It should be changed to the original image width and height for skipping. The bug located in file: TAppEncTop.cpp, line 226 in function Void TAppEncTop::xCreateLib() current: m_cTVideoIOYuvInputFile.skipFrames(m_FrameSkip, m_iSourceWidth, m_iSourceHeight); should be: m_cTVideoIOYuvInputFile.skipFrames(m_FrameSkip, m_iSourceWidth-m_aiPad[0], m_iSourceHeight-m_aiPad[1]);" taoranlu HM-5.2 380 single frame sequence decoding fails to write YUV file HM HM-5.2 defect closed 2012-03-05T15:14:21+01:00 2012-03-05T15:15:01+01:00 "from email report (Uday Krishna G): While decoding a single frame using HM-6.0rc1 Decoder, it shows error message: ""failed to write reconstructed YUV file"", but working fine for multiple frames. In case of IDR frame decoding, for single frame it is trying flush output before opening the recon file. So it fails to write the data to recon YUV. Code in HM-5.1 In file TAppDecTop.cpp, in decode( ) function, the following condition {{{ if(nalu.m_UnitType == NAL_UNIT_CODED_SLICE_IDR ) { xFlushOutput( pcListPic ); } }}} i changed code as follows, {{{ if(nalu.m_UnitType == NAL_UNIT_CODED_SLICE_IDR && !(uiPOC == 0)) { xFlushOutput( pcListPic ); } }}} then it is working fine. Is this change correct or any other solution?" ksuehring HM-5.1rc2 294 wrong chroma qp offset in intra loco configuration HM HM-5.1rc2 defect closed 2012-01-20T15:11:36+01:00 2012-01-20T15:32:34+01:00 "encoder_intra_loco.cfg contains: ChromaQpOffset : 2 ChromaQpOffset2nd : 2 which should be zero for common conditions" ksuehring HM-5.1rc1 290 configuration file option for G382 needed HM HM-5.1rc1 defect closed 2012-01-19T11:31:48+01:00 2012-02-29T07:14:44+01:00 "G382 can only be turned off setting the #define to zero To match the common coding conditions that has been done in HM-5.1rc2 A configuration file options needs to be added after HM-5.1" ksuehring HM-5.1 306 bugs in reference picture list code HM HM-5.1 defect closed 2012-02-03T21:34:33+01:00 2012-12-02T11:11:10+01:00 "1. HM5.1, TComSlice.cpp line 628: if(m_RefPicListModification.getRefPicListModificationFlagL0()) { for( i = 0; i < m_RefPicListModification.getNumberOfRefPicListModificationsL0(); i++) { for( cIdx = '''num_ref_idx_l1_active_minus1''' + 1; cIdx > i; cIdx-- ) m_apcRefPicList[0][ cIdx ] = m_apcRefPicList[0][ cIdx - 1]; ... num_ref_idx_l1_active_minus1 shall be num_ref_idx_l0_active_minus1 for this is modification for list 0. 2. TEncCAVLC.cpp line 907: if(pcSlice->getRefPicListModificationFlagLC()) { for (UInt i=0;igetNumRefIdx(REF_PIC_LIST_C);i++) { WRITE_FLAG( '''pcSlice->getListIdFromIdxOfLC'''(i), ""pic_from_list_0_flag"" ); WRITE_UVLC( pcSlice->getRefIdxFromIdxOfLC(i), ""ref_idx_list_curr"" ); } } pcSlice->getListIdFromIdxOfLC return 0 for list0 and 1 for list1. WD states pic_from_list_0_flag is 1 for list0 and 0 for list1. The code write 0 for list0 and 1 for list1, shall write 1 for list0 and 0 for list1. 3. TDecCAVLC.cpp line 1032: READ_FLAG( uiCode, ""ref_pic_list_modification_flag_lc"" ); rpcSlice->setRefPicListModificationFlagLC( uiCode ? 1 : 0 ); if(uiCode) { for (UInt i=0;igetNumRefIdx(REF_PIC_LIST_C);i++) { READ_FLAG( uiCode, ""pic_from_list_0_flag"" ); rpcSlice->setListIdFromIdxOfLC(i, uiCode); READ_UVLC( uiCode, ""ref_idx_list_curr"" ); rpcSlice->setRefIdxFromIdxOfLC(i, '''uiCode'''); rpcSlice->setRefIdxOfLC((RefPicList)rpcSlice->getListIdFromIdxOfLC(i), rpcSlice->getRefIdxFromIdxOfLC(i), i); } } The code select list0 when receiving pic_from_list_0_flag equals 0, and select list1 when receiving pic_from_list_0_flag equals 1. This is opposite to WD. " eeehey HM-5.1 292 Chroma scan type in NxN intra prediction units HM HM-5.1 defect closed 2012-01-20T02:58:01+01:00 2012-02-29T07:20:30+01:00 "The chroma scan type can be set incorrectly when all of the following are true: • Intra CU. • Four NxN luma prediction units. • Chroma prediction mode copied from luma prediction mode (e.g. intra_chroma_pred_mode=5). The actual intra chroma prediction mode for the CU is determined from Luma Partition 0 only. See the following: {{{ if( uiChromaPredMode == DM_CHROMA_IDX ) { uiChromaPredMode = pcCU->getLumaIntraDir( 0 ); } }}} However, for purposes of scan type derivation (diagonal, horizontal, vertical), the HM software can end up using four independent chroma scan types per CU. It incorrectly uses the luma intra prediction mode from Luma Partition 0, Partition 1, Partition 2, and Partition 3. The chroma scan type should based only on the actual chroma prediction mode used in each block. Therefore, the luma modes from Partitions 1-3 should not be used to determine the chroma scan type. I believe the relevant code causing this behaviour is in TComDataCU::getCoefScanIdx {{{ if( uiDirMode == DM_CHROMA_IDX ) { uiDirMode = getLumaIntraDir(uiAbsPartIdx); } }}} " bheng HM-5.1 296 X- and Y-positions are calculated wrong in TComPattern::initPattern HM HM-5.1 defect closed 2012-01-24T13:23:31+01:00 2014-10-15T17:45:47+02:00 "in TComPattern.cpp: initPattern( TComDataCU* pcCU, UInt uiPartDepth, UInt uiAbsPartIdx ) lines 177 and 178; uiCurrPicPelX and uiCurrPicPelY are calculated wrong. Instead of: UInt uiCurrPicPelX = pcCU->getCUPelX() + g_auiRasterToPelX[ g_auiZscanToRaster[uiAbsZorderIdx] ]; UInt uiCurrPicPelY = pcCU->getCUPelY() + g_auiRasterToPelY[ g_auiZscanToRaster[uiAbsZorderIdx] ]; the code should be: UInt uiCurrPicPelX = pcCU->getCUPelX() + g_auiRasterToPelX[ g_auiZscanToRaster[uiAbsPartIdx] ]; UInt uiCurrPicPelY = pcCU->getCUPelY() + g_auiRasterToPelY[ g_auiZscanToRaster[uiAbsPartIdx] ]; " Heribert Brust HM-5.1 298 Bug related to 1-pass / 2-pass ALF in HM5.1 (and HM 5.0) HM HM-5.1 defect closed 2012-01-27T11:10:26+01:00 2012-11-30T17:24:32+01:00 "We observed significant loss of BD-rate for 1-pass / 2-pass ALF in HM5.1 (and HM 5.0). The loss seems to be introduced when integrating JCTVC-G665 (prediction for ALF coefficients). In the function ""decideFilterShapeLuma"", filter coefficients are changed incorrectly by this bug. The recommended bug fix is attached. " yamakage HM-5.1 299 Deblocking filter has been always disabled on independent tile boundary HM HM-5.1 defect closed 2012-01-30T19:53:32+01:00 2012-03-21T16:23:59+01:00 "As a result of the integration of QP averaging for deblocking (from JCTVC-G1031), HM5.x deblocking filter is no longer applied across independent tile boundaries leaving very visible block artifacts on tile boundaries in some cases. Taking HM5.1-rc2 for example, the bug exists in two places of TComLoopFilter.cpp file: 1) From line 905 to 908, the following code will disable luma sample DLF if the neighbor CU is in another independent tile. if (!pcCUP) { return; } 2) From line 1220 to 1223, the following code will disable chroma sample DLF if the neighbor CU is in another independent tile. if (!pcCUP) { return; } From the code, it is clear that the implementer has chosen not to filter (i.e., return) when the neighboring QP is not available. We believe that the spirit of JCTVC-G1031 and WD 5 is to use both QP values and availability is not an issue since both QP values are available at the time the deblocking filter is applied. " shilin.xu HM-5.1 312 Redundant cbf_cb and cbf_cr flags when log2MaxTrafoSize is set to two HM HM-5.1 defect closed 2012-02-07T02:28:27+01:00 2014-11-17T11:10:24+01:00 "There are three redundant cbf_cb and cbf_cr flags for each 4x4 chroma TU when log2MaxTrafoSize is set to two. When log2MaxTrafoSize is set to two, there are only 4x4 luma TUs and 4x4 chroma TUs and every four luma TUs correspond to one cb TU and one cr TU. So only one set of cbf_cb and cbf_cr flags should be coded corresponding to every four cbf_luma flags. However, HM 5.1 software still codes one cbf_cb and cbf_cr flags corresponding to each cbf_luma when log2MaxTrafoSize is set to two, which causes three redundant cbf_cb and cbf_cr flags for each 4x4 chroma TU. The relevant code causing this behavior is in TDecEntropy::xDecodeTransformSubdiv {{{ Bool bFirstCbfOfCU = uiLog2TrafoSize == pcCU->getSlice()->getSPS()->getQuadtreeTULog2MaxSize() || uiTrDepth == 0 }}} It does not consider the case when log2MaxTrafoSize is set to two. So for each 4x4 luma TU, bFirstCbfOfCU is always true and there will always be a set of cbf_cb and cbf_cr coded. " zhyang HM-5.1 315 Alignment of WD description and software about QP wrapping HM HM-5.1 defect closed 2012-02-07T11:05:57+01:00 2012-02-24T17:57:04+01:00 "HM software misses the QP wrapping defined in WD text as follows: QPY = ( ( ( QPY,PREV + cu_qp_delta +52+ 2*QpBdOffsetY )%( 52 + QpBdOffsetY ) ) - QpBdOffsetY (7‑21) In CE4 common test settings, HM software does not send cu_qp_delta values that need the QP wrapping. So this fix does not change BD-rate results. In order to align WD description and software, it is recommended to fix this issue when HM-6.0 is released. Attachment is a patch to HM-5.1-dev-cleanup. #define FIX_CU_DQP_WRAP 1 ///< Fix wrapping of cu_qp_delta #if FIX_CU_DQP_WRAP #define RESET_QP_OFFSET 1 ///< This macro shall be set equal to 0 or removed when JCTVC-H0400 is integrated. #endif There is another issue that the QpBdOffsetY may not be used appropriately in HM software. (This issue is also related to ticket #313.) It is recommended that the RESET_QP_OFFSET macro is also integrated into HM-6.0 in order to avoid its impact on the QP wrapping fix. Then RESET_QP_OFFSET macro should be removed when JCTVC-H0400 is integrated. " kchono HM-5.1 317 Bug in construction of mvp candidates HM HM-5.1 defect closed 2012-02-08T18:37:02+01:00 2014-01-12T23:57:43+01:00 "When A0 and A1 candidate motion vectors are both not available, and several among B0, B1 and B2 candidates are available, the resulting mvp list may contain two Bx candidates instead of one as described in section 8.4.2.1.7 of WD5. Find attached a proposed patch against HM-5.1-dev-cleanup that corrects the problem in TComDataCU::fillMvpCand." tkunlin HM-5.1 314 Code bug in function xFindDistortionFrame() HM HM-5.1 enhancement closed 2012-02-07T09:44:50+01:00 2012-11-05T20:47:34+01:00 "The below code in the function xFindDistortionFrame(): --------------------------------------------------------- #if IBDI_DISTORTION Int iShift = g_uiBitIncrement; Int iOffset = 1<<(g_uiBitIncrement-1); #else UInt uiShift = g_uiBitIncrement<<1; #endif --------------------------------------------------------- When turn on flag IBDI_DISTORTION, iOffset is wrong value when BitDepth set to 8." chenm003 HM-5.1 316 Encoder log about the PCM setting is wrong HM HM-5.1 defect closed 2012-02-07T12:20:44+01:00 2012-02-29T17:31:01+01:00 "Encoder log file always says ""PCM:1"" even if PCM is disabled by using config parameters. The following line in TAppEncCfg.cpp printf(""PCM:%d "", ((1<>(std::istringstream &in, GOPEntry &entry) //input { + memset(&entry, 0, sizeof(entry)); in>>entry.m_iSliceType; in>>entry.m_iPOC; in>>entry.m_iQPOffset; diff --git a/source/Lib/TLibEncoder/TEncCavlc.cpp b/source/Lib/TLibEncoder/TEncCavlc.cpp index 77a4820..dd1ad97 100644 --- a/source/Lib/TLibEncoder/TEncCavlc.cpp +++ b/source/Lib/TLibEncoder/TEncCavlc.cpp @@ -549,6 +549,7 @@ Void TEncCavlc::codeSliceHeader ( TComSlice* pcSlice ) { WRITE_UVLC( 0, ""idr_pic_id"" ); WRITE_FLAG( 0, ""no_output_of_prior_pics_flag"" ); + pcSlice->setPOC(0); } else { diff --git a/source/Lib/TLibEncoder/TEncGOP.cpp b/source/Lib/TLibEncoder/TEncGOP.cpp index 1662fbd..5392d3b 100644 --- a/source/Lib/TLibEncoder/TEncGOP.cpp +++ b/source/Lib/TLibEncoder/TEncGOP.cpp @@ -141,7 +141,7 @@ Void TEncGOP::init ( TEncTop* pcTEncTop ) // ==================================================================================================================== // Public member functions // ==================================================================================================================== -Void TEncGOP::compressGOP( Int iPOCLast, Int iNumPicRcvd, TComList& rcListPic, TComList& rcListPicYuvRecOut, std::list& accessUnitsInGOP) +Void TEncGOP::compressGOP( Int& iPOCLast, Int iNumPicRcvd, TComList& rcListPic, TComList& rcListPicYuvRecOut, std::list& accessUnitsInGOP) { TComPic* pcPic; TComPicYuv* pcPicYuvRecOut; @@ -286,6 +286,9 @@ Void TEncGOP::compressGOP( Int iPOCLast, Int iNumPicRcvd, TComList& rc pcSlice->setSliceType(P_SLICE); } #endif + if (getNalUnitType(uiPOCCurr) == NAL_UNIT_CODED_SLICE_IDR) + iPOCLast = 0; + // Set the nal unit type pcSlice->setNalUnitType(getNalUnitType(uiPOCCurr)); // Do decoding refresh marking if any diff --git a/source/Lib/TLibEncoder/TEncGOP.h b/source/Lib/TLibEncoder/TEncGOP.h index 9ab1c3b..c3cfb45 100644 --- a/source/Lib/TLibEncoder/TEncGOP.h +++ b/source/Lib/TLibEncoder/TEncGOP.h @@ -129,7 +129,7 @@ public: Void destroy (); Void init ( TEncTop* pcTEncTop ); - Void compressGOP ( Int iPOCLast, Int iNumPicRcvd, TComList& rcListPic, TComList& rcListPicYuvRec, std::list& accessUnitsInGOP ); + Void compressGOP ( Int& iPOCLast, Int iNumPicRcvd, TComList& rcListPic, TComList& rcListPicYuvRec, std::list& accessUnitsInGOP ); #if TILES_DECODER Void xWriteTileLocationToSliceHeader (OutputNALUnit& rNalu, TComOutputBitstream*& rpcBitstreamRedirect, TComSlice*& rpcSlice); #endif }}}" chenm003 HM-5.0 230 HM-4.1-dev crash when SBACRD set to zero HM HM-5.0 defect closed 2011-12-06T13:01:35+01:00 2014-01-11T20:38:53+01:00 When I turn off SBACRD, the HM will crash by pointer NULL. chenm003 HM-5.0 254 enc/dec mismatch and decoder crash when MaxPartitionDepth (m_uiMaxCUDepth) != 4 HM HM-5.0 defect closed 2011-12-27T08:02:28+01:00 2012-01-12T19:14:18+01:00 "enc/dec mismatch and decoder crash when MaxPartitionDepth (m_uiMaxCUDepth) != 4 '''exsample for mismatch''' BQSquare_q27_ld -f 8 --MaxPartitionDepth=3 POC 0 TId: 0 ( I-SLICE, QP 27 ) [DT 0.010] [L0 ] [L1 ] [MD5:650422e7623ee3aa0023dc8f6b9df668,(OK)] POC 1 TId: 0 ( B-SLICE, QP 30 ) [DT 0.010] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:832e5ba74046788f9bea2e16fce5bb7b,\ (***ERROR***)] [rxMD5:8028b13e927fd57e65927afb2589c190] '''exsample for crash test set''' BQSquare_q32_ld -f 8 --MaxPartitionDepth=3 BQSquare_q37_ld -f 8 --MaxPartitionDepth=3 BasketballPass_q22_ld -f 8 --MaxPartitionDepth=3 BasketballPass_q32_ld -f 8 --MaxPartitionDepth=3 BasketballPass_q37_ld -f 8 --MaxPartitionDepth=3 BlowingBublles_q22_ld -f 8 --MaxPartitionDepth=3 BlowingBublles_q32_ld -f 8 --MaxPartitionDepth=3 BlowingBublles_q37_ld -f 8 --MaxPartitionDepth=3 RaceHorses_wqvga_q27_ld -f 8 --MaxPartitionDepth=3 RaceHorses_wqvga_q32_ld -f 8 --MaxPartitionDepth=3 RaceHorses_wqvga_q37_ld -f 8 --MaxPartitionDepth=3" Tomohiro Ikai HM-5.0 235 Encoding crash when QuadtreeTUMaxDepthInter=4 (related to NSQT) HM HM-5.0 defect closed 2011-12-16T07:00:57+01:00 2012-11-30T04:49:09+01:00 "An encoding crash (release version) was observed at second frame on windows when QuadtreeTUMaxDepthInter was set to 4. Please find my config file in the attachment. According to valgrind, invalid write occurred several times such as in function xIT. However, the bug has not been located. It is believed that the bug is related to NSQT since the crash disappears when NSQT is disabled in Typedef.h." Xiang Li HM-5.0 241 Assertion failure with --FramesToBeEncoded=1 on configurations with a GOP length > 1 HM HM-5.0 defect closed 2011-12-19T15:36:37+01:00 2012-08-20T01:24:00+02:00 "{{{ /users/davidf/project/build/jctvc-hm-amd64/jctvc-tmuc-enc-v0.3-1371-gb444223-heads-df-4.1-fixes \ -c ~/project/jctvc-hm/@//cfg//encoder_randomaccess.cfg \ -c ~/project/jctvc-hm/@//cfg//per-sequence/BQSquare.cfg \ --InputFile=/users/davidf/work/video/BQSquare_416x240_60.yuv \ --BitstreamFile=out.bit \ --ReconFile=out.bit.yuv \ --FramesToBeEncoded=1 }}} jctvc-tmuc-enc-v0.3-1371-gb444223-heads-df-4.1-fixes: /users/davidf/project/jctvc-hm//.git/../@/source/Lib/TLibEncoder/TEncGOP.cpp:1722: Void TEncGOP::compressGOP(Int, Int, TComList&, TComList&, std::list&): Assertion `m_iNumPicCoded == iNumPicRcvd' failed. m_iNumPicCoded = 0, iNumPicRcvd = 1" davidf HM-5.0 243 Random Access Decoding using -s parameter in the decoder is broken HM HM-5.0 defect closed 2011-12-20T05:22:29+01:00 2012-03-29T16:44:22+02:00 Random access decoding from an IDR or a CRA NAL unit type used to be enabled in the decoder with the -s parameter. This parameter no longer work for the CRA case since before HM3.0 or HM4.0 when the NAL unit type encoding / decoding was modified. tktan HM-5.0 249 valgrind error in ALF decoding: HM HM-5.0 defect closed 2011-12-22T15:39:49+01:00 2012-01-04T21:19:39+01:00 "Applies to version HM-5.0 and HM-5.0rc1. When decoding a sequence with ALF, valgrind reports the use of uninitialised values in TComAdaptiveLoopFilter::calcVar, line 1378. No MD5 mismatches have been found yet. Encoder command line: -c encoder_lowdelay.cfg -c RaceHorsesC.cfg -i RaceHorses_832x480_30.yuv -b ./test.bit -o ./test.yuv --FramesToBeEncoded=10 --ALF=1 --SAO=0 This is the new version of calcVar introduced as a result of G609. The issue goes away if macro G609_NEW_BA_SUB is set to 0. It's possibly due to the use of a local array with padding not properly initialised. Setting the loop parameters to m_img_{height,width} - 3 instead of m_img_{height,width} + 3 removes the problem, but produces a different bit stream. It's unclear to me what the correct bounds should be." thomasd HM-5.0 250 decoder crashes again for low QP HM HM-5.0 defect closed 2011-12-22T16:10:53+01:00 2012-01-04T21:16:20+01:00 "I tested HM-5.0 using the following command line, but unfortunately, the decoder crashed again. TAppEncoder -c encoder_intra.cfg -c SteamLocomotiveTrain_10bit.cfg -q 12 -fs 289 -f 1 It seems that the crashing is also caused by the ALF." libin HM-5.0 253 Compilation Error when #define INTER_RPS_PREDICTION is set to 0. HM HM-5.0 defect closed 2011-12-24T00:04:48+01:00 2011-12-24T07:34:00+01:00 "The delclaration of GOPEntry was changed between HM5.0-rc1 (r1671) and HM5.0-tag (r1681). The additional part did not enclosed the variables that are not available when #define INTER_RPS_PREDICTION is set to 0 within #if INTER_RPS_PREDICTION ... #endif. Rickard Sjöberg spotted this and provided the attached patch. The patch looks correct to me." tktan HM-5.0 255 Potential Bug in HM (both in 4.0 and 5.0) HM HM-5.0 defect closed 2011-12-27T13:55:35+01:00 2014-12-02T11:24:49+01:00 "When we did expeiments on HM4.0, we observed that the following section of the code does not seem to behave in the correct way.In the function ""encodeResAndCalcRdInterCU"" in the file ""TEncSearch.cpp"". In the section ""Residual coding"", after calculating the best RD cost. if ( pcCU->isSkipped(0) ) { pcCU->setCbfSubParts( 0, 0, 0, 0, pcCU->getDepth( 0 ) ); } To my understanding, this is similar to the case when the value of bSkipRes is true. Therefore, it seems that the above code should be changed to if ( pcCU->isSkipped(0) ) { pcCU->setCbfSubParts( 0, 0, 0, 0, pcCU->getDepth( 0 ) ); pcCU->setTrIdxSubParts( 0, 0, pcCU->getDepth(0) ); } " NaZhang HM-5.0 256 HM-5.0 crashes when Independent Tiles is used HM HM-5.0 defect closed 2011-12-28T03:40:44+01:00 2012-01-04T16:51:22+01:00 "The Tiles related configuration that are used (using encoder_randomaccess.cfg): UniformSpacingIdc : 1 TileBoundaryIndependenceIdc : 1 NumTileColumnsMinus1 : 1 NumTileRowsMinus1 : 1 TileLocationInSliceHeaderFlag : 1 TileMarkerFlag : 1 Crash happens in function: Void TComLoopFilter::xEdgeFilterLuma( TComDataCU* pcCU, UInt uiAbsZorderIdx, UInt uiDepth, Int iDir, Int iEdge ) The configuration that causes the crash seems to be TileBoundaryIndependenceIdc setting. When it is set to 0, no problem occurs. Furthermore, the problem may be related to the macro DBF_DQP. When the macro is set to 0, the software runs without any problem even with TileBoundaryIndependenceIdc = 1." hendry HM-5.0 257 Null Pointer check missing HM HM-5.0 defect closed 2011-12-28T11:06:40+01:00 2012-03-21T16:26:25+01:00 "The line: iQP_P = pcCUP->getQP(uiPartPIdx) in functions: TComLoopFilter::xEdgeFilterChroma() and TComLoopFilter::xEdgeFilterLuma() need a NULL pointer check. The scenario occurs for sliceMode=1. " csghone HM-5.0 258 Uninitialized variables in TComSlice HM HM-5.0 defect closed 2011-12-28T11:12:23+01:00 2012-01-04T16:23:29+01:00 "In case sliceMode=1, some variables are left uninitialized in second slice onwards leading to invalid access and crash. List of variables: m_RefPicListModification.m_bRefPicListModificationFlagL0 m_RefPicListModification.m_bRefPicListModificationFlagL1 m_RefPicListModification.m_uiNumberOfRefPicListModificationsL0 m_RefPicListModification.m_uiNumberOfRefPicListModificationsL1 This initialization is needed as part of TComSlice::copySliceInfo() as well to fix the problem for sliceMode=1. " csghone HM-5.0 260 two corner case issues with r1686 HM HM-5.0 defect SimonO closed 2011-12-29T20:25:33+01:00 2012-01-16T18:18:07+01:00 "This ticket is related to ticket #232. when using the attached configuration amendment, decoding failed. By disabling macro PREDTYPE_CLEANUP, the deocoding can finish the whole stream. But there was encoding/decoding mismatch. Please refer to the attached log file. Looks like the problem was in deblocking module." peisongc HM-5.0 261 wavefrontsynchro=1 causes decoder crashes HM HM-5.0 defect closed 2012-01-03T09:35:46+01:00 2012-01-03T11:48:52+01:00 "A newly introduced CABAC context (m_cCUSigCoeffGroupSCModel) is not being saved correctly in the encoder when WaveFrontSynchro is activated in the config. This causes decoder mismatches and crashes. Although the minimum change is just to save the context correctly in TEncSbac::xCopyContextsFrom, the attached patches change both TEncSbac::xCopyContextsFrom and TDecSbac::xCopyContextsFrom, replacing the by-name context copies with a single memcpy. This will avoid future problems like this." gordon HM-5.0 262 Decoder crash in low QP test HM HM-5.0 defect closed 2012-01-04T03:46:59+01:00 2012-01-04T15:43:16+01:00 "HM 5.0 decoder crashes in AI_HE configuration in sequences Kimono,ChinaSpeed,SlidShows at QP=12 with the following assertion failed message: Void TComInputBitstream::read (UInt uiNumberOfBits, UInt& ruiBits) { ............. assert(m_fifo_idx + num_bytes_to_load < m_fifo->size()); ............. } " yjpiao HM-5.0 265 DisableInter4x4=0 induces Hm5.0 decoder crash HM HM-5.0 defect SimonO closed 2012-01-05T15:43:21+01:00 2012-01-12T19:16:56+01:00 "== Encoder == Encoder was run with parameter '''--DisableInter4x4=0''': bin/TAppEncoderStatic -c cfg/encoder_randomaccess.cfg --FrameRate=30 --FramesToBeEncoded=300 --SourceHeight=480 --SourceWidth=832 --InputFile=orig/RaceHorses_832x480_30.yuv --IntraPeriod=32 --DisableInter4x4=0 --QP=39 --SEIpictureDigest=0 --BitstreamFile=test.hvc --ReconFile=enc.yuv == Decoder == The decoder crashes with a segmentation fault: Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 7 TComPic::getNumPartInCU() /home/wien/work/workspace-hevc-hm/HM5.0/source/Lib/TLibCommon/TComPic.h:115 0x0806356d 6 TComLoopFilter::xDeblockCU() /home/wien/work/workspace-hevc-hm/HM5.0/source/Lib/TLibCommon/TComLoopFilter.cpp:243 0x08095f4e 5 TComLoopFilter::loopFilterPic() /home/wien/work/workspace-hevc-hm/HM5.0/source/Lib/TLibCommon/TComLoopFilter.cpp:179 0x08095e33 4 TDecGop::decompressGop() /home/wien/work/workspace-hevc-hm/HM5.0/source/Lib/TLibDecoder/TDecGop.cpp:417 0x0806c243 3 TDecTop::executeDeblockAndAlf() /home/wien/work/workspace-hevc-hm/HM5.0/source/Lib/TLibDecoder/TDecTop.cpp:236 0x0805316c 2 TAppDecTop::decode() /home/wien/work/workspace-hevc-hm/HM5.0/source/App/TAppDecoder/TAppDecTop.cpp:148 0x0804ee79 1 main() /home/wien/work/workspace-hevc-hm/HM5.0/source/App/TAppDecoder/decmain.cpp:79 0x0804c56b " mwi HM-5.0 266 ZERO_MVD_EST fix HM HM-5.0 defect closed 2012-01-06T06:59:28+01:00 2014-10-20T19:19:24+02:00 ZERO_MVD_EST(default: 0) bug is fixed. The related change is marked by ZERO_MVD_EST_FIX. Tammy HM-5.0 268 some memory handling issues HM HM-5.0 defect davidf closed 2012-01-06T11:13:52+01:00 2012-12-02T11:54:42+01:00 "The bitstream was generated with ./TAppEncoder -c ../cfg/encoder_randomaccess.cfg -c ../cfg/per-sequence/BQSQuare.cfg -g 8 -f 17 -q 37 with gcc 4.4.1 Here below is the valgrind memcheck output for decoder run with this bitstream. " kolya HM-5.0 269 Inconsistent signalling of merge flags triggers asserts HM HM-5.0 defect closed 2012-01-06T12:32:41+01:00 2014-01-11T20:54:16+01:00 "When HM-5.0 is run using RAHE standard conditions, but with Merge turned off (e.g. -0 MRG), an assert is triggered in TComPrediction::xWeightedAverage. This is caused by iRefIdx values not being properly set. Example command line: -c encoder_randomaccess.cfg -i BasketballPass_416x240_50.yuv -wdt 416 -hgt 240 -fr 50 -fs 0 -f 500 -0 MRG --ReconFile=nomerge.yuv --IntraPeriod=48 --InputBitDepth=8 -q 22 -b basketpass_qp22_no_merge_rahe.bin This issue seems to be caused by inconsistent signalling of whether Merge should be used for AMP or not. In xCompressCU, AMP Merge is always checked, even if the Merge option is switched off. This becomes an issue in TEncSearch::predInterSearch, where the main merge flag is checked (pcCU->getSlice()->getSPS()->getUseMRG()), rather than the supplied function parameter bUseMRG. The result is that the iRefIdx's are not properly set. There are two fixes for this problem. Either will prevent the assert being triggered. But it may be a good idea to apply both. Please see attached patch file for details. Fix 1 ----- Fix TEncCU.cpp, add some lines to xCompressCU to avoid AMP merge when the main merge flag is off. This means that the merge flag in the config file also switches AMP merge off. Fix 2 ----- Fix TEncSearch::predInterSearch so that it only uses the supplied function parameter bUseMRG. " stworrall HM-5.0 271 DecodingRefreshType=2 does not work correctly HM HM-5.0 defect closed 2012-01-09T15:11:53+01:00 2012-01-10T23:41:28+01:00 "The encoder does not set POC for IDR pictures that are not the first one to 0. This happens when DecodingRefreshType is set to 2 in the config file. Also, bumping does not work correctly for DecodingRefreshType=2. " rickard HM-5.0 272 Decoder crashes in deblocking when pictures are lost HM HM-5.0 defect closed 2012-01-09T15:46:12+01:00 2012-01-10T23:17:35+01:00 The decoder sometimes crash in deblocking when pictures are lost. rickard HM-5.0 273 Long-term picture decoder issue HM HM-5.0 defect closed 2012-01-09T15:47:44+01:00 2012-01-10T23:17:03+01:00 A picture buffer that has been used for long-term is not properly reset when the long-term is removed from the DPB. rickard HM-5.0 274 "Decoder temporal scaling flag ""-t"" does not work" HM HM-5.0 defect closed 2012-01-10T11:51:00+01:00 2012-01-10T23:16:29+01:00 "The decoder flag ""-t"" is supposed to enable decoding of temporal sub-streams. This does not work." rickard HM-5.0 275 Issue on intra chroma scanIdx value HM HM-5.0 defect closed 2012-01-10T18:45:07+01:00 2014-01-11T20:48:43+01:00 "According to section 8.5.2 of WD5d3, the scanIdx value for the intra chroma case should be : ScanType[ Log2( nS >> 2 ) ][ IntraPredModeC ]. The corresponding code in HM-5.0 is at line 4494 of TComDataCU.cpp: uiScanIdx = aucIntraDirToScanIdx[max(uiCTXIdx-1,0)][uiDirMode]; The code does not match WD5d3, as the corresponding scanIdx value would be : ScanType[ 1 + Log2( nS >> 2 ) ][ IntraPredModeC ]. As a consequence, levels of an intra chroma 8x8 block are always diagonal scanned regardless of IntraPredModeC. To match section 8.5.2 of WD5d3, line 4494 of TComDataCU.cpp should be: uiScanIdx = aucIntraDirToScanIdx[uiCTXIdx][uiDirMode];" tkunlin HM-5.0 278 Bugs of NSQT integration in deblocking filter HM HM-5.0 defect closed 2012-01-11T16:04:00+01:00 2012-11-30T04:45:44+01:00 "The bugs descripted below were reported by Van Der Auwera, Geert via JCT-VC reflector. The following is the related parts that cause bugs. 1. TComLoopFilter::xGetBoundaryStrengthSingle() ... if ( m_aapucBS[iDir][0][uiAbsPartIdx] && (pcCUQ->getCbf( uiPartQ, TEXT_LUMA, pcCUQ->getTransformIdx(uiPartQ)) != 0 | | pcCUP->getCbf( uiPartP, TEXT_LUMA, pcCUP->getTransformIdx(uiPartP) ) != 0) ) { uiBs = 2; } else ... In the case of NSQT, the functions getTransformIdx and getCbf will return the wrong data, because the NSQT ""non-square quadtree"" reuses ""square quadtree"" data structure in current HM. 2. TComLoopFilter::xSetEdgefilterTU() NSQT potentially splits a 16x4 or 4x16 TU further into 4x4 TUs. At xSetEdgefilterTU(), if non-square transform size is smaller than 8, the edges of 4x4 TUs will not be set to true. The patch for the bug fixed is attached. Through the tests, no impact on coding performance compared to HM5.0." xzheng HM-5.0 282 Strange behaviour observed in the HM-5.0 with quantization matrix HM HM-5.0 defect closed 2012-01-12T17:07:56+01:00 2012-01-12T19:13:41+01:00 "When using the quantization matrix the initial quantization scale (denoted as uiQ) is modified to obtain the scaled quantization scale (denoted as uiQW) according the following formula: uiQW = (uiQ<<4)/scaling_list[n]. where n denotes the coefficient position inside a given BxB TU. The shift by four bits (i.e. the multiplication by 16) is needed because the quantization matrix values are computed by multiplying their floating point values (picked by the HVS model that SONY is currently considering) by 16 and rounding them the nearest integer. In this setting, the following issue has been observed when the quantization matrices are used (i.e. --ScalingList=1). Suppose to provide the encoder with quantization matrices whereby all the values are equal to 16, from the previous formula it yields that uiQW = uiQ. In this case, the encoder that runs with these (special) quantization matrices must produce the same reconstructed sequence (i.e equal pixel-by-pixel) that would be produced when no quantization matrix is used. This happens to not be the case for the current HM-5.0 release. Attached there are also the log files for the first 8 frames of race_horses sequence, QP = 32, ld_he. As may be noted the PSNR for both case is different. The rate is different too but this is expectable as the encoder that uses quantization matrices must transmit them and thus ends up with a higher bitrate. " matteon HM-5.0 283 Weighted prediction table is written/read for entropy slices HM HM-5.0 defect ksuehring closed 2012-01-13T01:04:10+01:00 2012-01-13T01:09:45+01:00 "in codeSliceHeader / parseSliceHeader the weighted prediction table is called outside if(!bEntropySlice) " ksuehring HM-5.0 284 Unused context for cu_qp_delta syntax HM HM-5.0 defect davidf closed 2012-01-15T12:55:41+01:00 2012-01-15T22:56:58+01:00 There is an unused context for dqp syntax. Attachment includes an HM-5.0-dev-misc patch to remove the unused context. The removal reduces # of dqp contexts by one. Obviously, the patch introduces no changes in coding results. kchono HM-5.0 285 1-pass ALF encoder issue due to correlation calculations HM HM-5.0 defect closed 2012-01-16T13:49:54+01:00 2012-01-17T17:48:38+01:00 "This encoder issue does not affect common test condition results. In HM-5.0 1-pass ALF encoding, the filtering distortion estimation does not consider the 2 skipped lines per LCU if STAR_5x5 filter shape is selected. This problem may cause the filter shape decision biased when 1/2-pass ALF encoding is enabled. The fix is included by #if FIX_ONE_PASS in the following codes. Only one function needs to be modified: TEncAdaptiveLoopFilter::decideFilterShapeLuma {{{ Void TEncAdaptiveLoopFilter::decideFilterShapeLuma(Pel* ImgOrg, Pel* ImgDec, Int Stride, ALFParam* pcAlfSaved, UInt64& ruiRate, UInt64& ruiDist, Double& rdCost) { static Double **ySym, ***ESym; Int lambda_val = ((Int) m_dLambdaLuma) * (1<<(2*g_uiBitIncrement)); Int filtNo, filters_per_fr; Int64 iEstimatedDist; UInt64 uiRate; Double dEstimatedCost, dEstimatedMinCost = MAX_DOUBLE;; UInt uiBitShift = (g_uiBitIncrement<<1); #if FIX_ONE_PASS #if G1023_FIX_NPASS_ALF && G212_CROSS9x9_VB Int64 iEstimateDistBeforeFilter; Int* coeffNoFilter[NUM_ALF_FILTER_SHAPE][NO_VAR_BINS]; for(Int filter_shape = 0; filter_shape < NUM_ALF_FILTER_SHAPE; filter_shape++) { for(Int i=0; i< NO_VAR_BINS; i++) { coeffNoFilter[filter_shape][i]= new Int[ALF_MAX_NUM_COEF]; ::memset(coeffNoFilter[filter_shape][i], 0, sizeof(Int)*ALF_MAX_NUM_COEF); #if ALF_DC_OFFSET_REMOVAL coeffNoFilter[filter_shape][i][ m_sqrFiltLengthTab[filter_shape]-1 ] = (1 << ((Int)ALF_NUM_BIT_SHIFT)); #else coeffNoFilter[filter_shape][i][ m_sqrFiltLengthTab[filter_shape]-2 ] = (1 << ((Int)ALF_NUM_BIT_SHIFT)); #endif } } #endif #endif m_pcTempAlfParam->alf_flag = 1; #if !F747_APS m_pcTempAlfParam->cu_control_flag = 0; #endif m_pcTempAlfParam->chroma_idc = 0; m_pcTempAlfParam->alf_pcr_region_flag = m_uiVarGenMethod; #if !G212_CROSS9x9_VB //calculate correlation matrix (11x5) if(!m_bUseNonCrossALF) { xstoreInBlockMatrix(0, 0, m_img_height, m_img_width, true, true, ImgOrg, ImgDec, 2, Stride); } else { xstoreInBlockMatrixforSlices(ImgOrg, ImgDec, 2, Stride); } #endif for (int filter_shape = 0; filter_shape < NUM_ALF_FILTER_SHAPE ;filter_shape ++) { m_pcTempAlfParam->filter_shape = filtNo = filter_shape; m_pcTempAlfParam->num_coeff = m_sqrFiltLengthTab[filtNo] ; ESym = m_EGlobalSym [filtNo]; ySym = m_yGlobalSym [filtNo]; #if G212_CROSS9x9_VB if(!m_bUseNonCrossALF) { xstoreInBlockMatrix(0, 0, m_img_height, m_img_width, true, true, ImgOrg, ImgDec, filter_shape, Stride); } else { xstoreInBlockMatrixforSlices(ImgOrg, ImgDec, filter_shape, Stride); } #else xretriveBlockMatrix(m_pcTempAlfParam->num_coeff, m_iFilterTabIn11x5Sym[filtNo], m_EGlobalSym[2], ESym, m_yGlobalSym[2], ySym); #endif xfindBestFilterVarPred(ySym, ESym, m_pixAcc, m_filterCoeffSym, m_filterCoeffSymQuant, filtNo, &filters_per_fr, m_varIndTab, NULL, m_varImg, m_maskImg, NULL, lambda_val); //estimate R-D cost uiRate = xcodeFiltCoeff(m_filterCoeffSymQuant, filtNo, m_varIndTab, filters_per_fr, m_pcTempAlfParam); iEstimatedDist = xEstimateFiltDist(filters_per_fr, m_varIndTab, ESym, ySym, m_filterCoeffSym, m_pcTempAlfParam->num_coeff); #if FIX_ONE_PASS #if G1023_FIX_NPASS_ALF && G212_CROSS9x9_VB iEstimateDistBeforeFilter = xEstimateFiltDist(filters_per_fr, m_varIndTab, ESym, ySym, coeffNoFilter[filter_shape], m_pcTempAlfParam->num_coeff); iEstimatedDist -= iEstimateDistBeforeFilter; #endif #endif dEstimatedCost = (Double)(uiRate) * m_dLambdaLuma + (Double)(iEstimatedDist); if(dEstimatedCost < dEstimatedMinCost) { dEstimatedMinCost = dEstimatedCost; copyALFParam(pcAlfSaved, m_pcTempAlfParam); #if FIX_ONE_PASS #if G1023_FIX_NPASS_ALF && G212_CROSS9x9_VB iEstimatedDist += iEstimateDistBeforeFilter; #endif #endif for(Int i=0; i< filters_per_fr; i++ ) { iEstimatedDist += (((Int64)m_pixAcc_merged[i]) >> uiBitShift); } ruiDist = (iEstimatedDist > 0)?((UInt64)iEstimatedDist):(0); rdCost = dEstimatedMinCost + (Double)(ruiDist); ruiRate = uiRate; } } if (!m_iUsePreviousFilter) { decodeFilterSet(pcAlfSaved, m_varIndTab, m_filterCoeffSym); saveFilterCoeffToBuffer(m_filterCoeffSym, pcAlfSaved->filters_per_group, m_varIndTab, pcAlfSaved->alf_pcr_region_flag, pcAlfSaved->filter_shape); } if( m_iUsePreviousFilter ) { UInt64 uiOffRegionDistortion = 0; Int iPelDiff; Pel* pOrgTemp = (Pel*)ImgOrg; Pel* pDecTemp = (Pel*)ImgDec; for(Int y=0; y< m_img_height; y++) { for(Int x=0; x< m_img_width; x++) { if(m_maskImg[y][x] == 0) { iPelDiff = pOrgTemp[x] - pDecTemp[x]; uiOffRegionDistortion += (UInt64)( (iPelDiff*iPelDiff) >> uiBitShift ); } } pOrgTemp += Stride; pDecTemp += Stride; ruiDist += uiOffRegionDistortion; rdCost += (Double)uiOffRegionDistortion; } } #if FIX_ONE_PASS #if G1023_FIX_NPASS_ALF && G212_CROSS9x9_VB if(pcAlfSaved->filter_shape == ALF_STAR5x5) { Int iPelDiff; UInt64 uiSkipPelsDistortion = 0; Pel *pOrgTemp, *pDecTemp; for(Int y= m_lineIdxPadTop-1; y< m_img_height - m_lcuHeight ; y += m_lcuHeight) { pOrgTemp = ImgOrg + y*Stride; pDecTemp = ImgDec + y*Stride; for(Int x=0; x< m_img_width; x++) { if(m_maskImg[y][x] == 1) { iPelDiff = pOrgTemp[x] - pDecTemp[x]; uiSkipPelsDistortion += (UInt64)( (iPelDiff*iPelDiff) >> uiBitShift ); } } pOrgTemp += Stride; pDecTemp += Stride; for(Int x=0; x< m_img_width; x++) { if(m_maskImg[y+1][x] == 1) { iPelDiff = pOrgTemp[x] - pDecTemp[x]; uiSkipPelsDistortion += (UInt64)( (iPelDiff*iPelDiff) >> uiBitShift ); } } } ruiDist += uiSkipPelsDistortion; rdCost += (Double)uiSkipPelsDistortion; } for(Int filter_shape = 0; filter_shape < NUM_ALF_FILTER_SHAPE; filter_shape++) { for(Int i=0; i< NO_VAR_BINS; i++) { delete[] coeffNoFilter[filter_shape][i]; } } #endif #endif } }}} " chiayang_tsai HM-5.0 286 SliceMode 2 does not work HM HM-5.0 defect closed 2012-01-16T17:02:09+01:00 2012-01-17T17:45:55+01:00 "SliceMode=2 was broken in November last year, in HM-4.1. A ticket (#225) was created which contains a patch that solved the problem in HM-4.1. During the HM 5 work, both SliceMode=1 and SliceMode=2 got broken. The SliceMode=1 problems were fixed in HM-5.0-dev-bugfix but SliceMode=2 currently (HM-5.0-dev-misc rev 1761) does not work. The attached patch fixes the problem for FAST_BIT_EST=0 by adding 3 lines of code. However, the patch does not fix the SliceMode=2 bug when FAST_BIT_EST is set to 1 which is the HM-5 default. The patch is the same as the patch in #225 except that the changes are surrounded by ""#if !FAST_BIT_EST"". Note that this ticket makes ticket #225 obsolete. " rickard HM-5.0 287 num_reorder_frames is coded twice HM HM-5.0 defect ksuehring closed 2012-01-17T10:37:54+01:00 2012-01-17T14:37:36+01:00 "The syntax element ""num_reorder_frames"" has been implemented twice in the SPS (in macros MAX_DPB_AND_LATENCY and G1002_RPS)" jonatan HM-5.0 288 Encoding crash when EntropySliceMode is set to 1 or 2 HM HM-5.0 defect closed 2012-01-17T14:44:31+01:00 2013-01-27T18:55:18+01:00 Entropy slice doesn't work in HM5 by encoder crash when EntropySliceArgument indicates actual entropy slicing within a picture. In HM4, it works correctly without error. Tammy HM-5.0 247 APS does not use the header trace file functionality HM HM-5.0 enhancement closed 2011-12-21T12:47:41+01:00 2012-08-20T00:40:34+02:00 APS does not use the header trace file functionality that was introduced during the Torino meeting. For debugging it would be helpful to have a complete trace file (as we had it in previous standardization projects). ksuehring HM-5.0 251 HM-5.0 referencing structure HM HM-5.0 enhancement new 2011-12-23T04:28:53+01:00 2014-01-11T20:49:40+01:00 "It will be very difficult for a beginner to set the following referecing structure correctly. Such as # Type POC QPoffset QPfactor temporal_id ref_buf_size ref_pic #ref_pics reference pictures predict deltaRIdx-1 deltaRPS #ref_idcs reference idcs Frame1: B 8 1 0.442 0 4 1 4 -8 -10 -12 -16 0 Frame2: B 4 2 0.3536 0 2 1 3 -4 -6 4 1 0 4 5 1 1 0 0 1 Frame3: B 2 3 0.3536 0 2 1 4 -2 -4 2 6 1 0 2 4 1 1 1 1 Frame4: B 1 4 0.68 0 2 0 4 -1 1 3 7 1 0 1 5 1 0 1 1 1 Frame5: B 3 4 0.68 0 2 0 4 -1 -3 1 5 1 0 -2 5 1 1 1 1 0 Frame6: B 6 3 0.3536 0 2 1 4 -2 -4 -6 2 1 0 -3 5 1 1 1 1 0 Frame7: B 5 4 0.68 0 2 0 4 -1 -5 1 3 1 0 1 5 1 0 1 1 1 Frame8: B 7 4 0.68 0 2 0 4 -1 -3 -7 1 1 0 -2 5 1 1 1 1 0 It will be very difficult if a beginner wants to change the GOP size or the number of referenc frames. It would be helpful if we keep two referencing structure setting methods, one is professional way, the other is simple way. In the professinal way, the referencing structure is set as above. In the simple way, the referencing structure is set by the parameters deleted in r1614, such as RateGOPSize : 4 # GOP size used for QP assignment NumOfReference : 4 # Number of reference frames NumOfReferenceB_L0 : 2 # Number of reference frames for L0 for B-slices NumOfReferenceB_L1 : 2 # Number of reference frames for L1 for B-slices HierarchicalCoding : 0 # Hierarchical B coding ON/OFF LowDelayCoding : 1 # Low-delay coding structure GPB : 1 # Replace P-slice by B-slice using two same directions NRF : 0 # Mark non-reference for highest temporal layer BQP : 1 # Use hier-B style QP assignment for hier-P structure And one more parameter which limits the max_num_ref_pics is required. When setting the referencing structure in the simple way, the encoder will decide how to encode the whole sequences. In JM, we have two ways to set the coding structure, in HM if we also have two ways to set the referencing structure, it will be helpful." libin HM-4.1 228 input arguments -o and -b seems not work for encoder HM HM-4.1 defect closed 2011-12-01T22:30:29+01:00 2011-12-06T17:23:22+01:00 using version 4.1 tung.nguyen HM-4.1 229 LFCrossSliceBoundaryFlag mistake between cfg_file and code HM HM-4.1 defect closed 2011-12-02T11:37:29+01:00 2012-11-30T17:31:49+01:00 "In cfg file the LFCrossSliceBoundaryFlag was defined as ""# 0:not across, 1: across"" In code the flag was defined as ""0: Cross-slice-boundary in-loop filtering 1: non-cross-slice-boundary in-loop filtering""" chenm003 HM-4.1 231 N-pass ALF bug when STAR_CROSS_SHAPES is defined in HM-4.0 HM HM-4.1 defect closed 2011-12-08T14:08:42+01:00 2012-11-30T04:47:21+01:00 "When STAR_CROSS_SHAPES is defined, a bug is found when 2-pass ALF is enabled (ALFEncodePassReduction = 2). The pointer (m_iPreviousFilterShape) should be assigned to the current buffer (m_iPreviousFilterShapeMethods[m_uiVarGenMethod]) after the best filter shape is decided. This bug does not affect common test condition. === Solution for HM-4.0 === In Line 2574, TEncAdaptiveLoopFilter.cpp, the following code should be inserted: #if STAR_CROSS_SHAPES_LUMA m_iPreviousFilterShape =m_iPreviousFilterShapeMethods[m_uiVarGenMethod]; #endif " chiayang_tsai HM-4.1 232 HM-4.1-dev-entropy (r1596) decoder crash HM HM-4.1 defect closed 2011-12-13T22:29:26+01:00 2012-01-16T19:31:43+01:00 "HM-4.1-dev-entropy (r1596) decoder crashed when decoding a bitstream generated by the following configuration -c ..\cfg\encoder_lowdelay.cfg -c ..\cfg\per-equence\RaceHorsesC.cfg -c encoder_my.cfg -f 2 encoder_my.cfg is attached here." peisongc HM-4.1 234 BelowLeft LCU availability check when TileBoundaryIndependenceIdc = 0 HM HM-4.1 defect closed 2011-12-14T21:57:19+01:00 2012-12-02T11:52:03+01:00 In the current HM implementaion, the BelowLeft neighbouring LCU is always unavailable. However, when TileBoundaryIndependenceIdc = 0 and the BelowLeft LCU belongs to another tile, it is possible that the BelowLeft LCU is available. We have provided a patch to address this corner case bug. shilin.xu HM-4.1 236 Tiles parameter naming convention change HM HM-4.1 defect closed 2011-12-16T19:53:29+01:00 2011-12-24T07:57:08+01:00 "The most recent WD text change two tiles parameters from ""tile_boundary_independence_idc"" and ""uniform_spacing_idc"" to ""tile_boundary_independence_flag"" and ""uniform_spacing_flag"", so we would like to make the same change in HM code to correspond to the WD test. The places of the HM code which should be changed are: 1) In codePPS() function of TEncCavlc.cpp file, WRITE_FLAG( pcPPS->getUniformSpacingIdr(), ""uniform_spacing_idc"" ); WRITE_FLAG( pcPPS->getTileBoundaryIndependenceIdr(), ""tile_boundary_independence_idc"" ); 2) In codeSPS() function of TEncCavlc.cpp file, WRITE_FLAG( pcSPS->getUniformSpacingIdr(), ""uniform_spacing_idc"" ); WRITE_FLAG( pcSPS->getTileBoundaryIndependenceIdr(), ""tile_boundary_independence_idc"" ); 3) In parsePPS() function of TDecCAVLC.cpp file, READ_FLAG ( uiCode, ""uniform_spacing_idc"" ); READ_FLAG ( uiCode, ""tile_boundary_independence_idc"" ); 4) In parseSPS() function of TDecCAVLC,cpp file, READ_FLAG ( uiCode, ""uniform_spacing_idc"" ); READ_FLAG ( uiCode, ""tile_boundary_independence_idc"" ); What we would like to do is change the ""idc"" to ""flag""." shilin.xu HM-4.1 239 Bug in derivation of valMps in ContextModel::init(...) HM HM-4.1 defect closed 2011-12-18T10:59:57+01:00 2011-12-19T17:05:03+01:00 "In branch HM-4.1-dev-entropy-misc revision 1661, in TLibCommon/ContextModel.cpp, in ContextModel::init(...) function, valMps is not always correctly derived (see accompanying patch file). Fixing the issue has almost no impact on the BD bit rate (less than 0.04% difference without recalculation of context model initializations)." Heiner Kirchhoffer HM-4.1 227 MAX_CU_DEPTH is 7 HM HM-4.1 enhancement closed 2011-11-30T05:29:56+01:00 2013-01-31T13:34:07+01:00 "In TComRom.h, there MAX_CU_DEPTH is 7, but I guess MAX_CU_DEPTH is 6 in the draft. Here is my patch based branch HM-4.1-dev. diff --git a/source/Lib/TLibCommon/TComDataCU.cpp b/source/Lib/TLibCommon/TComDataCU.cpp index 3a89a29..db3a03d 100644 --- a/source/Lib/TLibCommon/TComDataCU.cpp +++ b/source/Lib/TLibCommon/TComDataCU.cpp @@ -4338,8 +4338,6 @@ UInt TComDataCU::getCoefScanIdx(UInt uiAbsPartIdx, UInt uiWidth, Bool bIsLuma, B }, {0, 1, 2, 0, 0, 1, 1, 0, 2, 2, 0, 0, 1, 1, 0, 0, 2, 2, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 2, 2, 2, 2, 0, 0, 0 }, - {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 - }, }; UInt uiCTXIdx; diff --git a/source/Lib/TLibCommon/TComPrediction.cpp b/source/Lib/TLibCommon/TComPrediction.cpp index dde10ca..c4f1f7b 100644 --- a/source/Lib/TLibCommon/TComPrediction.cpp +++ b/source/Lib/TLibCommon/TComPrediction.cpp @@ -637,7 +637,11 @@ Void TComPrediction::xPredIntraPlanar( Int* pSrc, Int srcStride, Pel* rpDst, Int Int k, l, bottomLeft, topRight; Int horPred; +#if PLANAR_F483 + Int leftColumn[MAX_CU_SIZE+1], topRow[MAX_CU_SIZE+1], bottomRow[MAX_CU_SIZE+1], rightColumn[MAX_CU_SIZE+1]; +#else Int leftColumn[MAX_CU_SIZE], topRow[MAX_CU_SIZE], bottomRow[MAX_CU_SIZE], rightColumn[MAX_CU_SIZE]; +#endif UInt blkSize = width; UInt offset2D = width; UInt shift1D = g_aucConvertToBit[ width ] + 2; diff --git a/source/Lib/TLibCommon/TComRom.h b/source/Lib/TLibCommon/TComRom.h index cecb457..8912380 100644 --- a/source/Lib/TLibCommon/TComRom.h +++ b/source/Lib/TLibCommon/TComRom.h @@ -50,7 +50,7 @@ // Macros // ==================================================================================================================== -#define MAX_CU_DEPTH 7 // log2(LCUSize) +#define MAX_CU_DEPTH 6 // log2(LCUSize) #define MAX_CU_SIZE (1<<(MAX_CU_DEPTH)) // maximum allowable size of CU #define MIN_PU_SIZE 4 #define MAX_NUM_SPU_W (MAX_CU_SIZE/MIN_PU_SIZE) // maximum number of SPU in horizontal line " chenm003 HM-4.0 206 HM-4 decoder crashes on ARM HM HM-4.0 defect closed 2011-08-29T10:57:52+02:00 2014-02-12T15:24:55+01:00 "HM 4.0 decoder (compiled with GCC 4.5.2 on Linux32 for ARM platform) crashes with anchor streams at the first Inter picture, either with ""segmentation fault"" or with the following assertion failed message: TComPrediction.cpp:501: Void TComPrediction::xPredInterBi(TComDataCU*, UInt, Int, Int, TComYuv*&, Int): Assertion `iRefIdx[iRefList] < pcCU->getSlice()->getNumRefIdx(eRefPicList)' failed. " alfonso HM-4.0 208 Wrong number of contexts defined for inter prediction direction HM HM-4.0 defect closed 2011-08-31T08:10:30+02:00 2014-01-11T20:37:15+01:00 "The number of contexts for coding inter prediction direction is defined as: #define NUM_INTER_DIR_CTX 4 ///< number of context models for inter prediction direction When DNB_INTER_PRED_MODE is defined, there are actually 5 contexts being used in TDecSbac::parseInterDir: ContextModel *pCtx = m_cCUInterDirSCModel.get( 0 ); ... pCtx++; m_pcTDecBinIf->decodeBin( uiSymbol, *( pCtx + 3 ) ); This fifth context, not being properly defined, is aliased with the first context of m_cCURefPicSCModel " fbossen HM-4.0 214 remove transform reordering for 0.5Nx2N transform HM HM-4.0 defect closed 2011-09-12T17:38:05+02:00 2011-12-22T08:04:23+01:00 "At HM4, when 0.5Nx2N transform is used, 0.5Nx2N input array is reodered to 2Nx0.5N array, and then 2N-pt transform is done followed by 0.5N-pt transform at encoder side. At decoder side, 0.5N-pt inv-transform is done prior to 2N-pt inv-transform when 0.5Nx2N transform is used. After transformation, 2Nx0.5N output array is reordered to 0.5Nx2N array. To be consistent with other transform processes, transform data reordering for 0.5Nx2N transform need to be removed. The attached is the files relate to the modification. After the removal of transform reordering, no impact on coding efficiency. The below is the results compared to HM4. || ||Random Access HE|| || || || ||Y|| U|| V|| ||Class A||0.0%|| -0.1%||-0.1%|| ||Class B||0.0%|| 0.0% ||0.0%|| ||Class C||0.0%|| 0.0% ||0.0%|| ||Class D||0.0%|| 0.1% ||0.0%|| ||Class E|| || || || ||Overall||0.0%||0.0%||0.0%|| || ||0.0%||0.0%|| 0.0%|| ||Enc Time[%]|| 100%|| || || ||Dec Time[%]|| 101%|| || || || ||Random Access LC|| || || || ||Y|| U|| V|| ||Class A||0.0%|| 0.1% ||0.0%|| ||Class B||0.0%|| 0.0% ||0.1%|| ||Class C||0.0%|| 0.0% ||0.0%|| ||Class D||0.0%|| -0.1% ||0.0%|| ||Class E|| || || || ||Overall||0.0%||0.0%||0.0%|| || ||0.0%||0.0%|| 0.0%|| ||Enc Time[%]|| 100%|| || || ||Dec Time[%]|| 100%|| || || || ||Low delay B HE|| || || || ||Y|| U|| V|| ||Class A|||| |||| ||Class B||0.0%|| -0.2%||-0.1%|| ||Class C||0.0%|| -0.1%||0.0%|| ||Class D||0.0%|| 0.1% ||-0.2%|| ||Class E||-0.1%||-0.1%||0.2% || ||Overall||0.0%||-0.1%||0.0%|| || ||0.0%||-0.1%||0.0%|| ||Enc Time[%]|| 100%|| || || ||Dec Time[%]|| 99%|| || || || ||Low delay B LC|| || || || ||Y|| U|| V|| ||Class A|||| |||| ||Class B||0.0%|| 0.0%|| 0.1%|| ||Class C||0.0%|| 0.0%||-0.1%|| ||Class D||0.0%|| 0.2%||-0.1%|| ||Class E||0.0%|| 0.1%||-0.1%|| ||Overall||0.0%|| 0.1%||-0.1%|| || ||0.0%|| 0.0%||-0.1%|| ||Enc Time[%]|| 100%|| || || ||Dec Time[%]|| 98%|| || || " xzheng HM-4.0 225 SliceMode 2 does not work in HM-4.1 HM HM-4.0 defect closed 2011-11-17T13:45:28+01:00 2012-01-16T19:36:42+01:00 SliceMode=2 is the slice mode that uses a byte threshold for breaking slices, it can for instance be used for creating 1500 byte slices. This mode does not work in HM-4.1 since the bitcounter is not set correctly when OL_USE_WPP=1. The attached patch fixes the problem by adding 3 lines of code. rickard HM-4.0 205 HM-4.0 ENC_DEC_TRACE flag HM HM-4.0 defect closed 2011-08-25T22:12:41+02:00 2011-08-26T11:34:42+02:00 In both HM-4.0 (1354) and HM-4.0-dev-bugfix (1358), when ENC_DEC_TRACE is set as 1 for debugging purpose, there are errors, which are caused by MRG_AMVP_FIXED_IDX_F470. jaekim HM-4.0 207 HM4.0 encoder issue on chroma ALF for multiple slice coding HM HM-4.0 defect closed 2011-08-29T15:49:03+02:00 2011-09-27T15:20:05+02:00 "ALF coefficient design for Cr uses Cb information when coding multiple slices per picture. This does not affect coding results for the common test conditions (i.e., single slice per picture), but affects when multiple slice coding is enabled such as CE8.c.5 and CE8.c.6. Suggested change is as follows: In TEncAdaptiveLoopFilter.cpp, line 6130, xCalcCorrelationFuncforChromaSlices(ALF_Cb, pOrg, pCmp, iShape, pcPicOrg->getCStride(), pcPicDec->getCStride()); should be modified to the following: xCalcCorrelationFuncforChromaSlices(ALF_Cr, pOrg, pCmp, iShape, pcPicOrg->getCStride(), pcPicDec->getCStride()); (the first argument should be modified from ALF_Cb to ALF_Cr.) " yamakage HM-4.0 209 bugs regarding FINE_GRANULARITY_SLICES macro HM HM-4.0 defect closed 2011-08-31T18:09:11+02:00 2011-08-31T20:54:20+02:00 "When the FINE_GRANULARITY_SLICES macro is turned off, the following compiling errors come out on the deocoder side: \hm-4.0\source\lib\tlibdecoder\tdeccu.cpp(399) : error C2065: 'ruiIsLast' : undeclared identifier \hm-4.0\source\lib\tlibdecoder\tdeccu.cpp(412) : error C2065: 'ruiIsLast' : undeclared identifier \hm-4.0\source\lib\tlibdecoder\tdeccu.cpp(429) : error C2065: 'ruiIsLast' : undeclared identifier " shilin.xu HM-4.0 210 Bug related to CAVLC coding HM HM-4.0 defect closed 2011-09-05T13:34:48+02:00 2012-02-10T23:52:42+01:00 "When encoding some sequences with very low QP, (such as SlideShow_1280x720_20, intra_loco, QP=2, RDOQ off, frame 2), the encoding crashed. That was caused by the limitation of the length of one code word in CAVLC. In that extreme case, some coefficients may be very large (more than 16000), and assert( uiNumberOfBits <= 32 ); in TComOutputBitstream::write() fails." libin HM-4.0 211 A mismatch between WD and HM about ALF slice boundary padding HM HM-4.0 defect closed 2011-09-06T08:16:51+02:00 2011-10-14T07:16:05+02:00 "There is a mismatch between WD and HM software, In WD (8.6.3.1), the slice boundary padding size depends on the ALF filter size. In HM software, the boundary padding size is fixed. This mismatch only affects the results when the following 2 conditions are both satisfied 1. Multiple slices in one picture 2. ALF is not allowed to cross slice boundary This mismatch does not affect the results of common test conditions." chiayang_tsai HM-4.0 212 encoder crashes when one slice size is only 16x16 pixels HM HM-4.0 defect closed 2011-09-06T08:52:28+02:00 2011-09-27T15:12:42+02:00 "The encoder crashes when a rare slice setting is used: 1. SliceGranularity : 2 2. SliceMode : 1 3. SliceArgument : 1 4. LFCrossSliceBoundaryFlag : 0 This is a rare case. It does not affect the results of common test conditions" chiayang_tsai HM-4.0 213 Encoder problem when PCM and sub-CU dQP are used HM HM-4.0 defect closed 2011-09-08T11:21:36+02:00 2012-01-15T23:04:06+01:00 "TEncCu::xCheckIntraPCM() misses dQP checking and it may cause encoder-decoder mismatches. A patch for this fix based on HM-4.0 is attached. Please note that the problem happens only when both PCM and dQP are enabled and therefore it does not affect any results in common test conditions." hao HM-4.0 215 Decoding crashed with very low QP HM HM-4.0 defect closed 2011-09-13T09:59:00+02:00 2014-01-11T20:35:23+01:00 The decoding crashed with default RA_LC, LB_LC, LP_LC setting, SlideEditing, QP=2. libin HM-4.0 216 Bug in Alpha bits of chroma from luma mode HM HM-4.0 defect closed 2011-09-30T03:50:45+02:00 2011-10-25T02:48:40+02:00 "In the current implementation, when (alpha >63 or <=-64), the is down-scaled with ""a = a >> (6-n);"" (On Line 1434 @ TComPrediction.cpp ) This operation should be replaced by ""a = a >> (9-n);"" With this bug fix, Around Avg. -0.5% uv BD rate saving is achieved. " jlchen HM-4.0 217 1-pass ALF problem when STAR_CROSS_SHAPES_LUMA is defined (Not affect common test condition)) HM HM-4.0 defect closed 2011-10-13T09:12:52+02:00 2011-10-14T07:14:40+02:00 "This problem does not happen in common test condition. It only happens when g_uiMaxCUDepth is equal to 0 and 1-pass ALF is applied. When STAR_CROSS_SHAPES_LUMA is defined, the selected filter shape for training new coefficients may be wrong. == solution == One-line fix. In Line 4851, TencAdaptiveLoopFilter.cpp, add the following code. #if STAR_CROSS_SHAPES_LUMA copyALFParam(m_pcTempAlfParam, &cAlfParam); #endif " chiayang_tsai HM-4.0 218 Memory allocation in TComAdaptiveLoopFilter::create HM HM-4.0 defect closed 2011-10-18T19:04:09+02:00 2011-10-18T19:57:42+02:00 "In TComAdaptiveLoopFilter::create() memory is allocated using: get_mem2Dpel(&(m_varImgMethods[i]), m_img_width, m_img_width); This should probably be: get_mem2Dpel(&(m_varImgMethods[i]), m_img_height, m_img_width); With usual ""landscape"" picture dimensions this should not be a problem, but for ""portrait"" formats the allocated memory is not sufficient." ksuehring HM-4.0 219 Incorrect binarization of LastSignificantCoeffXY HM HM-4.0 defect closed 2011-10-19T12:30:02+02:00 2011-12-22T08:07:02+01:00 "This should use TU binarization according to the WD, but codes 000...1 instead of 111...0 i.e. the role of 1 and 0 is reversed. Context initialisation will also need to be modified. " thomasd HM-4.0 220 ALF variable is not correctly assign when STAR_CROSS_SHAPES_LUMA is defined (encoder issue) HM HM-4.0 defect closed 2011-10-19T13:44:30+02:00 2011-10-23T13:13:05+02:00 "In Line 4826, TEncAdaptiveLoopFilter.cpp filtNo is assigned as a temporary filter shape selection but not the final decision. The final decision in this for loop is cAlfParam.realfiltNo. In Line 4930, TEcnAdaptiveLoopFilter.cpp filtNo is used but not correctly assigned. filtNo should be assigned as cAlfParam.realfiltNo somewhere before Line 4930. The fix is as attached. " chiayang_tsai HM-4.0 221 Macro is missing in last position coding HM HM-4.0 defect closed 2011-10-27T09:24:08+02:00 2012-08-20T01:26:31+02:00 "In TEncSbac::codeLastSignificantXY() and TDecSbac::parseLastSignificantXY() of HM4.0, QC_MDCS macro are missing around swap code. Problem is occurred when MODFIED_LAST_CODING is defined, but QC_MDCS is not. if( uiScanIdx == SCAN_VER ) { swap( uiPosX, uiPosY ); } Above codes should be changed to the following. #if QC_MDCS if( uiScanIdx == SCAN_VER ) { swap( uiPosX, uiPosY ); } #endif" secret9th HM-4.0 222 Non-working code of early skip decision HM HM-4.0 defect closed 2011-10-27T14:42:45+02:00 2013-07-26T10:10:08+02:00 "In the function xCompressCU in TEncCU.cpp: Fast early decision based on threshold is implemented, but the variable fRD_Skip is never updated, thus early skip is not working now. Since two similar proposals (JCTVC-F045 and JCTVC-F092) were included in the software (and controlled by configuration option), these unnecessary codes can be removed." wjhan HM-4.0 223 Wrong derivation of deblocking filter boundary for non-square transform unit HM HM-4.0 defect closed 2011-10-30T11:11:46+01:00 2011-12-19T21:27:06+01:00 "At Line 391 @ TComLoopFilter.cpp, the value of parameter ""iBaseUnitIdx"" should be set as ""const UInt iBaseUnitIdx = uiLCUWidthInBaseUnits >> ( uiDepth + 2 );"" instead of ""const UInt iBaseUnitIdx = uiLCUWidthInBaseUnits >> ( uiDepth + 1 );"". Considering that non-square transform block will be split to four smaller blocks with half horizontal and vertical size at this condition, the parameter ""iBaseUnitIdx"" is set to a wrong value at HM4.0. This bug doesn't influence all the testing cases under common test condition. But it could cause mismatch if ""QuadtreeTUMaxDepthInter"" is set to 1. Compared to HM4.0-dev-1354 version, the performance of the bug fixed version under common test condition is as follow: || ||Random Access HE|| || || || ||Y|| U|| V|| ||Class A||0.0%|| -0.2%||-0.1%|| ||Class B||0.0%|| 0.0% ||0.1%|| ||Class C||0.0%|| 0.0% ||0.1%|| ||Class D||0.0%|| 0.0% ||0.0%|| ||Class E|| || || || ||Class F||-0.1%||-0.1%||-0.1%|| ||Overall||0.0%||0.0%||0.0%|| || ||0.0%||0.0%|| 0.0%|| ||Enc Time[%]|| 100%|| || || ||Dec Time[%]|| 99%|| || || || ||Random Access LC|| || || || ||Y|| U|| V|| ||Class A||0.0%|| 0.0% ||0.0%|| ||Class B||0.0%|| 0.0% ||0.1%|| ||Class C||0.0%|| 0.0% ||0.0%|| ||Class D||0.0%|| 0.0% ||0.0%|| ||Class E|| || || || ||Class F||0.0%||-0.1%||0.0%|| ||Overall||0.0%||0.0%||0.0%|| || ||0.0%||0.0%|| 0.0%|| ||Enc Time[%]|| 100%|| || || ||Dec Time[%]|| 100%|| || || || ||Low delay B HE|| || || || ||Y|| U|| V|| ||Class A|||| |||| ||Class B||0.0%|| -0.1%||-0.2%|| ||Class C||0.0%|| 0.1%||-0.1%|| ||Class D||0.0%|| 0.5% ||-0.1%|| ||Class E||-0.1%||0.0%|| 0.1% || ||Class F||-0.1%||-0.1%||0.0% || ||Overall||0.0%||0.1%||-0.1%|| || ||0.0%||-0.1%||0.0%|| ||Enc Time[%]|| 100%|| || || ||Dec Time[%]|| 98%|| || || || ||Low delay B HE|| || || || ||Y|| U|| V|| ||Class A|||| |||| ||Class B||0.0%|| 0.1%|| 0.2%|| ||Class C||0.0%|| 0.1%||-0.2%|| ||Class D||0.0%|| 0.0% ||-0.2%|| ||Class E||-0.1%||-0.1%||-0.1% | ||Class F|| 0.1%|| 0.3%||0.0% || ||Overall||0.0%||0.1%||-0.1%|| || ||0.0%||-0.1%||0.0%|| || ||Enc Time[%]|| 100%|| || ||Dec Time[%]|| 98%|| || ||" xzheng HM-4.0 224 Bug regarding the tiles parameter coding in PPS & SPS HM HM-4.0 defect ksuehring closed 2011-11-11T01:38:53+01:00 2012-05-05T17:14:26+02:00 The implementation of the PPS and SPS syntax for tiles does not correctly reflect the syntax adopted in JCTVC-F335. shilin.xu HM-4.0 226 Encoder crashes on low QPs for LC case HM HM-4.0 defect closed 2011-11-18T12:08:28+01:00 2014-01-11T20:33:32+01:00 "./bin/TAppEncoderStaticd -c cfg/encoder_intra_loco.cfg -c cfg/per-seq uence/SlideShow.cfg -q 5 -b str/SlideShow_Q5_S64_H4_intra_loco.bin -o rec/SlideS how_Q5_S64_H4_intra_loco_enc.yuv -f 500 -ip 1 HM software: Encoder Version [4.0rc1][Linux][GCC 4.1.2][64 bit] Input File : /home/X0104A/DMC_HEVC/orig/SlideShow_1280x720_20.yuv Bitstream File : str/SlideShow_Q5_S64_H4_intra_loco.bin Reconstruction File : rec/SlideShow_Q5_S64_H4_intra_loco_enc.yuv Real Format : 1280x720 20Hz Internal Format : 1280x720 20Hz Frame index : 0 - 499 (500 frames) Number of Ref. frames (P) : 4 Number of Ref. frames (B_L0) : 2 Number of Ref. frames (B_L1) : 2 Number of Reference frames : 4 CU size / depth : 64 / 4 RQT trans. size (min / max) : 4 / 32 Max RQT depth inter : 3 Max RQT depth intra : 3 Min PCM size : 128 Motion search range : 64 Intra period : 1 Decoding refresh type : 0 QP : 5.00 Max dQP signaling depth : 0 GOP size : 1 Rate GOP size : 1 Internal bit depth : 8 PCM sample bit depth : 8 DisableInter4x4 : 1 Entropy coder : VLC TOOL CFG: ALF:0 IBD:0 HAD:1 SRD:0 RDQ:1 SQP:0 ASR:0 PAD:0 LDC:1 NRF:0 BQP:0 GPB:1 LComb:1 LCMod:0 FEN:1 ECU:0 CFM:0 RQT:1 MRG:1 LMC:1 Slice: G=0 M=0 EntropySlice: M=0 CIP:0 SAO:1 PCM:0 NewRefSetting:0 POC 0 TId: 0 ( I-SLICE, QP 5 ) 1775456 bits [Y 62.5820 dB U 62.0018 dB V 62.1815 dB] [ET 34 ] [L0 ] [L1 ] [MD5:e3b2adb62401dcd843e52da4ed3f7f27] POC 1 TId: 0 ( I-SLICE, QP 5 ) 7528 bits [Y 92.5911 dB U 89.7144 dB V 88.9681 dB] [ET 19 ] [L0 ] [L1 ] [MD5:b82c9d8b4544ad12f706aaee66ca6b09] POC 2 TId: 0 ( I-SLICE, QP 5 ) 4744 bits [Y 93.6265 dB U 90.9638 dB V 91.3417 dB] [ET 19 ] [L0 ] [L1 ] [MD5:93080cdccf53039cf6fcfbee74252cfe] POC 3 TId: 0 ( I-SLICE, QP 5 ) 132496 bits [Y 69.5920 dB U 69.5025 dB V 70.3474 dB] [ET 21 ] [L0 ] [L1 ] [MD5:6b9a073d65ecd44fbcae2f1e1fbfbf59] TAppEncoderStaticd: /home/X0104/e1niko/HM-4.0rc1-Fine/build/linux/lib/TLibCommon/../../../../source/Lib/TLibCommon/TComBitStream.cpp:95: virtual Void TComOutputBitstream::write(UInt, UInt): Assertion `uiNumberOfBits <= 32' failed. Crash was also observed on QPs from 1 to 9 on SlideShow for all LC configurations. " kolya HM-4.0 204 Unnecessary code HM HM-4.0 enhancement closed 2011-08-24T15:54:36+02:00 2011-08-31T08:29:50+02:00 Line 533 in TEncAdaptiveLoopFilter.cpp: dMinCost = dMinCost; tung.nguyen HM-3.4 199 [HM-3.4-dev-loop-filters] Mismatch happens when ALF = 1 and SliceMode !=0 HM HM-3.4 defect closed 2011-08-15T03:51:35+02:00 2011-08-18T09:59:30+02:00 "Mismatch happens when the following encoder parameters are set ALF :1 SliceMode: 1 SliceArgument : 5 LFCrossSliceBoundaryFlag : 0 The problem is observed from rev. 1185 of HM-3.4-dev-loop-filters branch." chiayang_tsai HM-3.4 200 Compile time error observed when CAVC_RDOQ_MOD was disabled with r1246. HM HM-3.4 defect closed 2011-08-17T02:18:34+02:00 2011-08-17T21:48:25+02:00 "When CAVC_RDOQ_MOD was disabled with r1246 , compile time error was observed at >..\..\source\Lib\TLibCommon\TComTrQuant.cpp(1424): error C2100: illegal indirection >..\..\source\Lib\TLibCommon\TComTrQuant.cpp(1945): error C2100: illegal indirection In ComTrQuant::bitCountRDOQ, when CAVC_RDOQ_MOD was enabled, vlc_adapative was declared as Int*. But when CAVC_RDOQ_MOD was disabled, vlc_adaptive was declared as Int. This inconsistency caused the compile time error at line 1424 and line 1945 with CAVLC_RDOQ_MOD disabled. " auyeung HM-3.4 128 Wrap-around problem with return variables from xCheckBestMVP HM HM-3.4 defect closed 2011-02-22T14:37:43+01:00 2011-08-17T08:42:46+02:00 "In some cases the ME (xMotionEstimation) is bypassed, but the function xCheckBestMVP is still invoked. In those cases the input variable uiBitsTemp holds the number of bits of the partition, but without the MV bits. Here's what happens in xCheckBestMVP: uiBitsTemp = uiBitsTemp - iOrgMvBits + iBestMvBits where iOrgMvBits is the bit-cost when original predictor is used, and iBestMvBits is the bit-cost for the new best predictor. It can happen that the difference of the original MV bits and new MV bits is larger than uiBitsTemp. This results in wrap around to the values from the upper end of the UInt range. Consequently, ruiBits and ruiCost (uiBitsTemp and uiCostTemp) values returned from the function xCheckBestMVP are wrong. This may affect result of the selection of MVs since uiBits[iRefList] = uiBitsTemp, and uiBits is used later in mode selection. Probably has only a minor effect on the results as the conditions are relatively rare. " nsprljan HM-3.4 136 Sparse images may cause the encoder to hang when ALF is on (observed only in release build) HM HM-3.4 defect closed 2011-03-29T23:04:55+02:00 2011-08-17T08:33:33+02:00 "The calculation of ALF coefficients is not robust for very sparse images. Simplest solution: Check the returned value by gnsSolveByChol(). If the return value indicates a singular case then assign filter coefficients arbitrarily #ifndef MOT_SPARSE_FIX gnsSolveByChol(E, y, filterCoeff, sqrFiltLength); #else int singular = gnsSolveByChol(E, y, filterCoeff, sqrFiltLength); if(singular == 0) { filterCoeff[0] = 1; for (i=1; igetSlice( 0 )->isReferenced() ) to if ( rpcPic->getSlice( 0 )->isReferenced() && rpcPic->getReconMark() ) Meanwile, it is better to do the same change for line 807." libin HM-3.4 202 If GOP size and intra period are same, decoder has mismatch HM HM-3.4 defect closed 2011-08-23T09:39:37+02:00 2013-02-04T11:44:06+01:00 "When I tested HM4.0rc1 using following TAppEncoder.exe -c encoder_randomaccess.cfg -c per-sequence/BQSquare.cfg -q 37 -g 16 -f 17 -ip 16 I got mismatch for decoder. (log is attatched) Based on the simple analysis, it seems that gop size estimation at decoder is a source of mismatch. In xGetNewPicBuffer(), gop size is estimated by assuming gop size is POC gap between first and second picture (P or B). However, when gop size and intra period are same, gop size is wrongly estimated as 0. One simple solution is to fix the value of variable m_iMaxRefPicNum such as 16. This is similar approach to H.264/AVC, but cost huge memory allocation in decoder. Need to find better solution for this. " secret9th HM-3.4 203 undefined memory access with SlideShow LP-LC QP=32 HM HM-3.4 defect closed 2011-08-24T14:31:49+02:00 2014-01-11T20:31:31+01:00 "A mismatch has been detected between running the encoder on different platforms for a particular specific sequence and configuration. Using the configuration: ftp://ftp.kw.bbc.co.uk/hevc/hm-4.0-anchors/logs.bbc/ldP_lc/SlideShow_1280x720_20/QP=32/encoder.cfg Further checking has with valgrind has revealed: {{{ POC 7 TId: 0 ( P-SLICE, QP 35 ) 8552 bits [Y 41.2143 dB U 46.6770 dB V 49.2018 dB] [ET 720 ] [L0 6 5 4 0 ] [L1 ] [MD5:a7df59fd976de5bfdc4c36a0558aba67] ==14058== Conditional jump or move depends on uninitialised value(s) ==14058== at 0x438C8B: TEncSearch::xCheckBestMVP(TComDataCU*, RefPicList, TComMv, TComMv&, int&, unsigned int&, unsigned int&) (in /dump/df-4.0rc1-anchors/bin/jctvc-tmuc-enc-28c4437-remotes-svn-upstream-tags-HM-4.0rc1) }}}" davidf HM-3.3 196 Assertion failure in TEncAdaptiveLoopFilter::gnsSolveByChol() HM HM-3.3 defect closed 2011-08-12T04:38:54+02:00 2011-08-17T08:33:08+02:00 "HM encoders fail to encode images whose pixel values are uniform or near-uniform. HM-3.2 or lower hangs up and HM-3.3 or higher stops with an assertion failure. An example command line for replicating the bug is: TAppEncoder.exe -c cfg/encoder_intra.cfg --InputFile=gray.yuv --SourceWidth=1280 --SourceHeight=720 --FrameRate=1 --FrameToBeEncoded=1 -q 37 where gray.yuv is the uniform byte array of 128. The error message from HM-3.4-dev r1246) is: Assertion failed: singular == 1, file ..\..\source\Lib\TLibEncoder\TEncAdaptiveLoopFilter.cpp, line 4287 " hao HM-3.3 192 Bug in HM3.3: fine slice granularity + ALF + loop filter across slices = 0 HM HM-3.3 defect closed 2011-07-07T22:57:44+02:00 2011-08-17T08:57:48+02:00 "Bug in HM3.3 (also in previous version). TComAdaptiveLoopFilter.cpp, setSGUBorderAvailability(). Line 2765: zRefSU = g_auiRasterToZscan[ rTRefSU+ 1]; should be replaced with zRefSU = g_auiRasterToZscan[ rTRefSU+ uiWidthSU]; Line 2775: zRefSU = g_auiRasterToZscan[ rTLSU - uiNumSUInLCUWidth +1]; should be replaced with zRefSU = g_auiRasterToZscan[ rTLSU - uiNumSUInLCUWidth +uiWidthSU]; These code try to refer to top-right block, but raster-index are wrong. " madhukar HM-3.3 190 Intra reference sample padding removes some frame-boundary samples HM HM-3.3 defect closed 2011-07-06T03:24:18+02:00 2011-08-17T08:45:54+02:00 When constrained intra prediction is disabled, the codes to check the availability of intra reference samples at above-right and below-left locations do not take care of frame boundary. When above-right and/or below-left neighboring blocks are partially available within the frame, their available samples are removed and padded with the last samples from above and/or left neighbors respectively. This bug was identified in HM-3.0 and is still present in HM-3.3 (rev 1106). vwahadaniah HM-3.3 194 significance bit estimation in RDOQ (PCP_SIGMAP_SIMPLE_LAST defined) HM HM-3.3 defect closed 2011-07-28T23:12:03+02:00 2015-03-26T15:08:32+01:00 "When PCP_SIGMAP_SIMPLE_LAST is defined (as default in HM-3.3 and HM-3.4), the last coefficient position is encoded before the significance map. During significance map coding, the position of the last significant coefficient is indicated by the already encoded LAST position, and thus not encoded. However, in the current RDOQ process, this is not taken into consideration: the significance map rate of the last significant coefficient is calculated and included into its RD cost, resulting in inaccurate estimation." jzan HM-3.3 193 Add SAO encoder parameters into HM config file HM HM-3.3 task closed 2011-07-14T16:32:03+02:00 2011-08-18T10:23:32+02:00 "Add SAO encoder parameters into HM config file {{{ SAO : 1 # Sample adaptive offset (0: OFF, 1: ON) }}} " chihming.fu HM-3.2 187 HM-3.2 crash (please see attached cfg) HM HM-3.2 defect closed 2011-07-05T19:12:56+02:00 2011-08-17T09:34:51+02:00 HM3.2 encoder generates non-compliant bitstreams with the attached config file, cfg1 (PCM is enabled and QP = 0): HM3.2 decoder crashes when it decodes the bitstream. madhukar HM-3.2 188 HM-3.2 encoder/decoder mismatch (please see attached cfg file) HM HM-3.2 defect closed 2011-07-05T19:14:28+02:00 2012-11-30T17:34:32+01:00 HM3.2 has encoder-decoder mismatch with the attached config file, cfg2 (DQP depth 1 and fine granularity slice with depth 3). madhukar HM-3.2 189 HM-3.2 encoder crash (please see attached cfg) HM HM-3.2 defect closed 2011-07-05T19:15:42+02:00 2011-08-17T09:35:48+02:00 HM3.2 encoder crashes with the attached config file, cfg3 (low-complexity, reference list combination = disabled). madhukar HM-3.2 184 HM3.2 Decoder crashing for QP=1 RA LC HM HM-3.2 defect closed 2011-06-20T19:20:15+02:00 2012-02-10T23:51:49+01:00 "For WVGA50_PartyScene for QP=1 for RA-LC configuration, decoder is crashing at different points for debug and release versions. For debug versions, 3 frames are decoded perfectly before failing at an assert statement. To replicate the crash, it is enough to encode just 9 frames and try to decode the bit-stream. Rajan Joshi Encoder and decoder logs: ============================== ./TAppEncoder.exe -c WVGA50_PartyScene.cfg -c c:/jctvc-hm/HM-3.2/cfg/encoder_randomaccess_loco.cfg --QP=1 HM software: Encoder Version [3.2][Windows][VS 1500][64 bit] Input File : Z:/WVGA50_PartyScene.yuv Bitstream File : str.bin Reconstruction File : rec.yuv Real Format : 832x480 50Hz Internal Format : 832x480 50Hz Frame index : 0 - 8 (9 frames) Number of Ref. frames (P) : 4 Number of Ref. frames (B_L0) : 2 Number of Ref. frames (B_L1) : 2 Number of Reference frames : 4 CU size / depth : 64 / 4 RQT trans. size (min / max) : 4 / 32 Max RQT depth inter : 3 Max RQT depth intra : 3 Min PCM size : 128 Motion search range : 64 Intra period : 32 Decoding refresh type : 1 QP : 1.00 GOP size : 8 Rate GOP size : 8 Internal bit depth : 8 PCM sample bit depth : 8 Entropy coder : VLC TOOL CFG: ALF:0 IBD:0 HAD:1 SRD:0 RDQ:1 SQP:0 ASR:0 PAD:0 LDC:0 NRF:1 BQP:0 GPB:1 LComb:1 LCMod:0 FEN:1 RQT:1 MRG:1 LMC:1 Slice: G=0 M=0 EntropySlice: M=0 CIP:0 SAO:1 PCM:0 POC 0 TId: 0 ( I-SLICE, QP 1 ) 3564352 bits [Y 72.9684 dB U 76.2205 dB V 76.3920 dB] [ET 8 ] [L0 ] [L1 ] [MD5:4a014a689b19ffbe3f0cc1d1a28d1d49] POC 8 TId: 0 ( B-SLICE, QP 2 ) 2962168 bits [Y 66.6797 dB U 66.0962 dB V 65.6417 dB] [ET 24 ] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:2525574474eda000560034193be6b941] POC 4 TId: 0 ( B-SLICE, QP 3 ) 2592408 bits [Y 62.2885 dB U 60.8419 dB V 60.2948 dB] [ET 29 ] [L0 0 8 ] [L1 8 0 ] [LC 0 8 ] [MD5:24270a8f58c1d5a3391d845559bf6722] POC 2 TId: 0 ( B-SLICE, QP 4 ) 304 bits [Y 72.9684 dB U 76.2205 dB V 76.3920 dB] [ET 12 ] [L0 0 4 ] [L1 4 8 ] [LC 0 4 8 ] [MD5:4a014a689b19ffbe3f0cc1d1a28d1d49] POC 6 TId: 0 ( B-SLICE, QP 4 ) 2371520 bits [Y 59.7857 dB U 58.5392 dB V 58.0699 dB] [ET 28 ] [L0 4 2 ] [L1 8 4 ] [LC 4 8 2 ] [MD5:78bdb78e3f5a759ddf43022ff1dedc1c] POC 1 TId: 0 ( B-SLICE, QP 5 ) 176 bits [Y 72.9684 dB U 76.2205 dB V 76.3920 dB] [ET 9 ] [L0 0 2 ] [L1 2 4 ] [LC 0 2 4 ] [MD5:4a014a689b19ffbe3f0cc1d1a28d1d49] POC 3 TId: 0 ( B-SLICE, QP 5 ) 1898832 bits [Y 55.8385 dB U 53.4906 dB V 52.8768 dB] [ET 26 ] [L0 2 0 ] [L1 4 6 ] [LC 2 4 0 6 ] [MD5:ce338e63d21ac6b47382c7ad70caa66b] POC 5 TId: 0 ( B-SLICE, QP 5 ) 1884744 bits [Y 55.8802 dB U 53.4773 dB V 52.8864 dB] [ET 28 ] [L0 4 2 ] [L1 6 8 ] [LC 4 6 2 8 ] [MD5:cb0c54aab6f1ef185090b6127adc5264] POC 7 TId: 0 ( B-SLICE, QP 5 ) 1876848 bits [Y 55.8591 dB U 53.4712 dB V 52.8791 dB] [ET 27 ] [L0 6 4 ] [L1 8 6 ] [LC 6 8 4 ] [MD5:ccace622a4818a7a342aa0732c412588] SUMMARY -------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 9 a 95285.2889 63.9152 63.8420 63.5361 I Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 1 i 178217.6000 72.9684 76.2205 76.3920 P Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 0 p -1.#IND -1.#IND -1.#IND -1.#IND B Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 8 b 84918.7500 62.7836 62.2947 61.9291 RVM: 0.000 Bytes written to file: 2144187 (95297.200 kbps) Total Time: 203.032 sec. $ ./TAppDecoder.exe -b str.bin Assertion failed: 0, file ..\..\source\Lib\TLibCommon\TComLoopFilter.cpp, line 349 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. " mcoban HM-3.2 186 EntropySliceMode 2 does not work properly HM HM-3.2 defect closed 2011-06-22T11:14:54+02:00 2011-08-17T08:51:46+02:00 "EntropySliceMode 2 does not work properly. (EntropySliceMode 2 break the bitstream into entropy slices when a bin count (CABAC) or a bit count (CAVLC) exceeds the threshold specified by the EntropySliceArgument parameter.) One problem is that when SliceMode is also 2, slice sizes could become significantly smaller than the specified threshold. This is fixed by ensuring that a CU which does not fit into the current entropy slice and is therefore not encoded does not count towards the budget for the current slice. Another problem is that when FINE_GRANULARITY_SLICES is defined, incorrect bin counting during compression meant that the compressor could give different results on random due to different CU splits. This is fixed by correctly initializing and updating the bin counter during compression. A fix reative revision 1085 of HM-3.2-dev that corrects entropy slice coding for EntropySliceMode 2 is attached. There are no modifications to the decoder, only encoder entropy slice decisions are changed. " rickard HM-3.2 201 Redundant computation in 1-pass ALF encoding for multi-slice picture HM HM-3.2 defect closed 2011-08-17T08:36:11+02:00 2011-08-18T10:15:30+02:00 "This redundat computation only happens when the following tools are both turned on: 1. One-pass ALF (ALFEncodePassReduction: 1 or 2) 2. Multi-slice picture (SliceMode : 1 or 2) Not affect common test condition and not affect one-slice picture case. === Problem statement === In TEncAdaptiveLoopFilter.cpp, Void TEncAdaptiveLoopFilter::xEncodeCUAlfCtrlFlags() { #if MTK_NONCROSS_INLOOP_FILTER if(m_uiNumSlicesInPic > 1) { for(UInt s=0; s< m_uiNumSlicesInPic; s++) { for(UInt idx=0; idx< m_pSlice[s].getNumLCUs(); idx++) { CAlfLCU& cAlfLCU = m_pSlice[s][idx]; for(UInt i=0; i< cAlfLCU.getNumCtrlFlags(); i++) { m_pcEntropyCoder->encodeAlfCtrlFlag(cAlfLCU.getCUCtrlFlag(i)); } } } } #endif for( UInt uiCUAddr = 0; uiCUAddr < m_pcPic->getNumCUsInFrame() ; uiCUAddr++ ) { TComDataCU* pcCU = m_pcPic->getCU( uiCUAddr ); xEncodeCUAlfCtrlFlag(pcCU, 0, 0); } } This function, xEncodeCUAlfCtrlFlags, is only used for 1-pass ALF to calculate the bitrate of ALF CU-on/off flags. When uiNumSlicesInPic > 1, there are redundant bitrate calculation. === Fix === Add one ""return"" for multi-slice picture case, the modification is as follows, Void TEncAdaptiveLoopFilter::xEncodeCUAlfCtrlFlags() { #if MTK_NONCROSS_INLOOP_FILTER if(m_uiNumSlicesInPic > 1) { for(UInt s=0; s< m_uiNumSlicesInPic; s++) { for(UInt idx=0; idx< m_pSlice[s].getNumLCUs(); idx++) { CAlfLCU& cAlfLCU = m_pSlice[s][idx]; for(UInt i=0; i< cAlfLCU.getNumCtrlFlags(); i++) { m_pcEntropyCoder->encodeAlfCtrlFlag(cAlfLCU.getCUCtrlFlag(i)); } } } return; } #endif for( UInt uiCUAddr = 0; uiCUAddr < m_pcPic->getNumCUsInFrame() ; uiCUAddr++ ) { TComDataCU* pcCU = m_pcPic->getCU( uiCUAddr ); xEncodeCUAlfCtrlFlag(pcCU, 0, 0); } }" chiayang_tsai HM-3.1 185 Improper TU size for NxN PU when max RQT depth = 1 HM HM-3.1 defect closed 2011-06-20T22:35:01+02:00 2014-11-14T18:39:16+01:00 We discovered a bug in HM-3.1 implementation of implicit RQT split for max depth=1 and PU split. Specifically, 2Nx2N TU for NxN PU in inter CU is chosen when NxN TU should be used. Krit HM-3.0rc2 152 When the macro MTK_TMVP_H_MRG is disabled, “iRefIdx = iRefIdxSkip[1];” is not set before calling xGetCenterCol() process. HM HM-3.0rc2 defect closed 2011-04-28T04:53:13+02:00 2011-05-17T20:23:13+02:00 "We have found a bug in HM3.0 which will impact CE1. (start from line 2412 in TComDataCU.cpp) {{{ #if PANASONIC_MRG_TMVP_REFIDX iRefIdx = iRefIdxSkip[1]; <--- This line should be added if ( xGetCenterCol( uiPUIdx, REF_PIC_LIST_1, iRefIdx, &cMvTCenter[1] ) ) #else }}} This will not impact the anchor of HM3.0 because this code section is bypassed when the macro MTK_TMVP_H_MRG is turned on, which is the default setting of HM3.0. However, this bug will impact CE1 when the macro MTK_TMVP_H_MRG is disabled. " JianLiangLin HM-3.0rc2 162 redundant code in slice header parsing in HM3.0 HM HM-3.0rc2 enhancement closed 2011-05-12T14:00:06+02:00 2011-05-30T01:11:38+02:00 "In function parseSliceHeader() in TDecCAVLC.cpp l.299 rpcSlice->setRefPicListCombinationFlag(false); is already set in l.279 xReadFlag (uiCode); rpcSlice->setRefPicListCombinationFlag(uiCode ? 1 : 0); and can be removed or moved to an else part of l.277 condition if (rpcSlice->isInterB())" bbross HM-3.0rc1 145 HM-3.0rc1, Assertion failure when decoding SEI message for some sequences HM HM-3.0rc1 defect davidf closed 2011-04-17T02:41:48+02:00 2011-04-17T07:17:21+02:00 "{{{ #0 0x00007fecc9d20165 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007fecc9d22f70 in abort () at abort.c:92 #2 0x00007fecc9d192b1 in __assert_fail (assertion=0x47bc17 ""0"", file=, line=205, function=0x47bd80 ""Void TComBitstream::read(UInt, UInt&)"") at assert.c:81 #3 0x0000000000418e3f in TComBitstream::read (this=, uiNumberOfBits=, ruiBits=) at /home/davidf/project/jctvc-tmuc/source/Lib/TLibCommon/TComBitStream.cpp:205 #4 0x000000000045c240 in read (bs=..., seis=...) at /home/davidf/project/jctvc-tmuc/source/Lib/TLibDecoder/../TLibCommon/TComBitStream.h:152 #5 parseSEImessage (bs=..., seis=...) at /home/davidf/project/jctvc-tmuc/source/Lib/TLibDecoder/SEIread.cpp:49 #6 0x000000000045d7b8 in TDecCavlc::parseSEI (this=0x7ffff17a8d58, seis=...) at /home/davidf/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecCAVLC.cpp:91 #7 0x0000000000476ed0 in decodeSEI (this=0x7ffff17a7af0, bEos=false, pcBitstream=0x2207e50, ruiPOC=, rpcListPic=, iSkipFrame=@0x7ffff17a7ae8, iPOCLastDisplay=@0x7ffff17b2bf8) at /home/davidf/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecEntropy.h:151 #8 TDecTop::decode (this=0x7ffff17a7af0, bEos=false, pcBitstream=0x2207e50, ruiPOC=, rpcListPic=, iSkipFrame=@0x7ffff17a7ae8, iPOCLastDisplay=@0x7ffff17b2bf8) at /home/davidf/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecTop.cpp:238 #9 0x000000000040545f in TAppDecTop::decode (this=0x7ffff17a7ad0) at /home/davidf/project/jctvc-tmuc/source/App/TAppDecoder/TAppDecTop.cpp:138 #10 0x0000000000406de8 in main (argc=3, argv=) at /home/davidf/project/jctvc-tmuc/source/App/TAppDecoder/decmain.cpp:76 }}}" davidf HM-3.0 161 source/Lib/TLibCommon/TComBitStream.cpp:203: Void TComInputBitstream::read(UInt, UInt&): Assertion `m_fifo_idx + num_bytes_to_load < m_fifo->size()' failed HM HM-3.0 defect closed 2011-05-11T17:15:23+02:00 2011-05-16T19:48:04+02:00 "From the current HM-3.0-dev r909: {{{ $ ./jctvc-tmuc-enc \ -c ~/rd/project/jctvc-tmuc//cfg//encoder_lowdelay_loco.cfg \ -c ~/rd/project/jctvc-tmuc//cfg//per-sequence/RaceHorses.cfg \ --InputFile=RaceHorses_416x240_30.yuv \ --FramesToBeEncoded=24 \ --BitstreamFile=out.bit \ --ReconFile=out.bit.yuv ... POC 0 TId: 0 ( I-SLICE, QP 32 ) 69648 bits [Y 34.1502 dB U 37.2259 dB V 37.6995 dB] [ET 3 ] [L0 ] [L1 ] [MD5:d45676bcc1e6cd96ef82d840f511065d] POC 1 TId: 0 ( B-SLICE, QP 35 ) 6920 bits [Y 31.4898 dB U 36.3927 dB V 36.6373 dB] [ET 6 ] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:7472c8042035b256e640dd7dc7038fb1] POC 2 TId: 0 ( B-SLICE, QP 34 ) 9424 bits [Y 31.3365 dB U 36.2060 dB V 36.4521 dB] [ET 10 ] [L0 1 0 ] [L1 1 0 ] [LC 1 0 ] [MD5:37d03ef12291c492d9242e93d915f34a] POC 3 TId: 0 ( B-SLICE, QP 35 ) 6920 bits [Y 30.5560 dB U 35.7810 dB V 35.7427 dB] [ET 13 ] [L0 2 1 0 ] [L1 2 1 0 ] [LC 2 1 0 ] [MD5:7e0e83766c20ed94579aa51e5de26cb5] POC 4 TId: 0 ( B-SLICE, QP 33 ) 28032 bits [Y 33.3721 dB U 36.8717 dB V 37.2671 dB] [ET 18 ] [L0 3 2 1 0 ] [L1 3 2 1 0 ] [LC 3 2 1 0 ] [MD5:c5f5b511f6afb74868ef7491cbfc8c4f] POC 5 TId: 0 ( B-SLICE, QP 35 ) 6056 bits [Y 31.4562 dB U 36.1094 dB V 36.4754 dB] [ET 15 ] [L0 4 3 2 1 ] [L1 4 3 2 1 ] [LC 4 3 2 1 ] [MD5:ac1521d95a02577d5146836b19dc503e] POC 6 TId: 0 ( B-SLICE, QP 34 ) 9032 bits [Y 31.1916 dB U 35.7949 dB V 36.1372 dB] [ET 16 ] [L0 5 4 3 2 ] [L1 5 4 3 2 ] [LC 5 4 3 2 ] [MD5:05f9be53552121d68717b0ba5a7ae5c9] POC 7 TId: 0 ( B-SLICE, QP 35 ) 7112 bits [Y 30.5432 dB U 35.2687 dB V 35.4717 dB] [ET 15 ] [L0 6 5 4 3 ] [L1 6 5 4 3 ] [LC 6 5 4 3 ] [MD5:4a4a735697d182d055b9cd1eef12b1ed] POC 8 TId: 0 ( B-SLICE, QP 33 ) 31400 bits [Y 33.2649 dB U 36.7103 dB V 37.0140 dB] [ET 18 ] [L0 7 6 5 4 ] [L1 7 6 5 4 ] [LC 7 6 5 4 ] [MD5:23d6785913d24eefd113f04cec0693ec] $ ./jctvc-tmuc-dec --BitstreamFile=out.bit ... POC 0 TId: 0 ( I-SLICE, QP 32 ) [DT 0.050] [L0 ] [L1 ] [MD5:d45676bcc1e6cd96ef82d840f511065d,(OK)] POC 1 TId: 0 ( B-SLICE, QP 35 ) [DT 0.010] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:7472c8042035b256e640dd7dc7038fb1,(OK)] POC 2 TId: 0 ( B-SLICE, QP 34 ) [DT 0.010] [L0 1 0 ] [L1 1 0 ] [LC 1 0 ] [MD5:37d03ef12291c492d9242e93d915f34a,(OK)] POC 3 TId: 0 ( B-SLICE, QP 35 ) [DT 0.020] [L0 2 1 0 ] [L1 2 1 0 ] [LC 2 1 0 ] [MD5:7e0e83766c20ed94579aa51e5de26cb5,(OK)] POC 4 TId: 0 ( B-SLICE, QP 33 ) [DT 0.030] [L0 3 2 1 0 ] [L1 3 2 1 0 ] [LC 3 2 1 0 ] [MD5:c5f5b511f6afb74868ef7491cbfc8c4f,(OK)] POC 5 TId: 0 ( B-SLICE, QP 35 ) [DT 0.020] [L0 4 3 2 1 ] [L1 4 3 2 1 ] [LC 4 3 2 1 ] [MD5:ac1521d95a02577d5146836b19dc503e,(OK)] POC 6 TId: 0 ( B-SLICE, QP 34 ) [DT 0.020] [L0 5 4 3 2 ] [L1 5 4 3 2 ] [LC 5 4 3 2 ] [MD5:05f9be53552121d68717b0ba5a7ae5c9,(OK)] jctvc-tmuc-dec: /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibCommon/TComBitStream.cpp:203: Void TComInputBitstream::read(UInt, UInt&): Assertion `m_fifo_idx + num_bytes_to_load < m_fifo->size()' failed. }}} Examining the stack trace: {{{ #2 0x00007ffff72d37c5 in __assert_fail (assertion=0x46bcd8 ""m_fifo_idx + num_bytes_to_load < m_fifo->size()"", file=, line=203, function=) at assert.c:81 #3 0x0000000000413cd2 in TComInputBitstream::read (this=0x8de8c0, uiNumberOfBits=1, ruiBits=@0x7fffffff2730) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibCommon/TComBitStream.cpp:203 #4 0x0000000000413b91 in TComInputBitstream::pseudoRead (this=0x8de8c0, uiNumberOfBits=6, ruiBits=@0x7fffffff2730) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibCommon/TComBitStream.cpp:157 #5 0x0000000000453299 in TDecCavlc::parseCbfTrdiv (this=0x7fffffff44a8, pcCU=0xc7ea10, uiAbsPartIdx=128, uiTrDepth=0, uiDepth=2, uiSubdiv=@0x7fffffff27dc) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecCAVLC.cpp:1922 #6 0x000000000045c4f4 in TDecEntropy::xDecodeTransformSubdiv (this=0x7fffffff4498, pcCU=0xc7ea10, uiAbsPartIdx=128, uiDepth=2, uiInnerQuadIdx=0, uiYCbfFront3=@0x7fffffff2884, uiUCbfFront3=@0x7fffffff2888, uiVCbfFront3=@0x7fffffff288c) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecEntropy.cpp:751 #7 0x000000000045d32d in TDecEntropy::decodeTransformIdx (this=0x7fffffff4498, pcCU=0xc7ea10, uiAbsPartIdx=128, uiDepth=2) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecEntropy.cpp:988 #8 0x000000000045da12 in TDecEntropy::decodeCoeff (this=0x7fffffff4498, pcCU=0xc7ea10, uiAbsPartIdx=128, uiDepth=2, uiWidth=16, uiHeight=16) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecEntropy.cpp:1164 #9 0x0000000000457666 in TDecCu::xDecodeCU (this=0x7fffffff4458, pcCU=0xc7ea10, uiAbsPartIdx=128, uiDepth=2) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecCu.cpp:325 #10 0x0000000000456eae in TDecCu::xDecodeCU (this=0x7fffffff4458, pcCU=0xc7ea10, uiAbsPartIdx=128, uiDepth=1) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecCu.cpp:216 #11 0x0000000000456eae in TDecCu::xDecodeCU (this=0x7fffffff4458, pcCU=0xc7ea10, uiAbsPartIdx=0, uiDepth=0) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecCu.cpp:216 #12 0x0000000000456af5 in TDecCu::decodeCU (this=0x7fffffff4458, pcCU=0xc7ea10, ruiIsLast=@0x7fffffff2d4c) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecCu.cpp:126 #13 0x0000000000464020 in TDecSlice::decompressSlice (this=0x7fffffff4438, pcBitstream=0x8de8c0, rpcPic=@0x7fffffffdeb0) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecSlice.cpp:105 #14 0x000000000045e3c2 in TDecGop::decompressGop (this=0x7fffffff41b0, bEos=false, pcBitstream=0x8de8c0, rpcPic=@0x7fffffffdeb0, bExecuteDeblockAndAlf=false) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecGop.cpp:176 (gdb) frame 5 #5 0x0000000000453299 in TDecCavlc::parseCbfTrdiv (this=0x7fffffff44a8, pcCU=0xc7ea10, uiAbsPartIdx=128, uiTrDepth=0, uiDepth=2,! uiSubdiv=@0x7fffffff27dc) at /users/davidf/rd/project/jctvc-tmuc/source/Lib/TLibDecoder/TDecCAVLC.cpp:1922 1922 m_pcBitstream->pseudoRead(6, uiSymbol); (gdb) print m_pcBitstream->getNumBitsLeft() $1 = 5 }}}" davidf HM-3.0 166 Encoder/Decoder Crash HM HM-3.0 defect closed 2011-05-19T02:19:28+02:00 2011-05-20T00:23:32+02:00 "Setting the ""ListCombination"" to ""0"" in ""encoder_lowdelay_loco.cfg"" (i.e. the LD-LC condition), usually causes the encoder to crash (after a few frames). In case that the encoder finishes without a crash, then decoding of the generated bitstream would result in a Decoder crash. Note that the exact frame where the crash happens is intermittent and depends on the hw/sw platform as well as the coded sequence. Comment: As replacing the CAVLC with CABAC would fix the problem, most likely the culprit is in the CAVLC/LCEC module. " minoo HM-3.0 179 Decoding mismatch when MaxDeltaQP = 2 HM HM-3.0 defect closed 2011-05-30T23:53:51+02:00 2011-07-05T20:08:42+02:00 "Decoding mismatch was observed when MaxDeltaQP=2 (HM3.0). For example for RaceHorses_832x480_30.yuv, QP=37, 60 frames, lowdelay setting, decoding mismatch occurs. Commandline ""--MaxDeltaQP=2"" is used to set MaxDeltaQP to 2. The encoding and decoding logs are as follows. Encoding: HM software: Encoder Version [3.0][Windows][VS 1500][32 bit] Input File : C:\Test_Sequences\RaceHorses_832x480_30.yuv Bitstream File : 37.bin Reconstruction File : 37.yuv Real Format : 832x480 30Hz Internal Format : 832x480 30Hz Frame index : 0 - 59 (60 frames) Number of Ref. frames (P) : 4 Number of Ref. frames (B_L0) : 2 Number of Ref. frames (B_L1) : 2 Number of Reference frames : 4 CU size / depth : 64 / 4 RQT trans. size (min / max) : 4 / 32 Max RQT depth inter : 3 Max RQT depth intra : 3 Motion search range : 64 Intra period : -1 Decoding refresh type : 0 QP : 37.00 GOP size : 1 Rate GOP size : 4 Internal bit depth : 10 Entropy coder : CABAC TOOL CFG: ALF:1 IBD:1 HAD:1 SRD:1 RDQ:1 SQP:0 ASR:0 PAD:0 LDC:1 NRF:0 BQP:1 GPB:1 LComb:1 LCMod:0 FEN:1 RQT:1 MRG:1 LMC:1 Slice:0 EntropySlice:0 CIP:0 SAO:1 POC 0 ( I-SLICE, QP 37 ) 120344 bits [Y 31.9047 dB U 35.5105 dB V 36.6706 dB] [ET 27 ] [L0 ] [L1 ] [MD5:27d35840064a53ff746e342fe7ab8198] POC 1 ( B-SLICE, QP 40 ) 9080 bits [Y 29.6193 dB U 34.5536 dB V 35.5787 dB] [ET 39 ] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:6917ca1fc8e3e1d7516e22a78f64a6bc] POC 2 ( B-SLICE, QP 39 ) 10768 bits [Y 29.3094 dB U 34.3362 dB V 35.3311 dB] [ET 60 ] [L0 1 0 ] [L1 1 0 ] [LC 1 0 ] [MD5:4e3a93c981e7b579ff1516510b16ac3c] POC 3 ( B-SLICE, QP 40 ) 8840 bits [Y 28.7353 dB U 34.1365 dB V 34.8921 dB] [ET 70 ] [L0 2 1 0 ] [L1 2 1 0 ] [LC 2 1 0 ] [MD5:b2f2d6231a16d342c28fa51334bf055b] POC 4 ( B-SLICE, QP 38 ) 41496 bits [Y 30.9714 dB U 35.0948 dB V 36.0387 dB] [ET 99 ] [L0 3 2 1 0 ] [L1 3 2 1 0 ] [LC 3 2 1 0 ] [MD5:9e022e223488e6eb0b134caba9acf75c] POC 5 ( B-SLICE, QP 40 ) 7872 bits [Y 29.4708 dB U 34.3611 dB V 35.3934 dB] [ET 75 ] [L0 4 3 2 1 ] [L1 4 3 2 1 ] [LC 4 3 2 1 ] [MD5:f6f946003b5da492a460be1d14090d0c] POC 6 ( B-SLICE, QP 39 ) 10656 bits [Y 29.1827 dB U 34.1852 dB V 34.9174 dB] [ET 82 ] [L0 5 4 3 2 ] [L1 5 4 3 2 ] [LC 5 4 3 2 ] [MD5:7e79fa528a780e58f43ee935388b889c] POC 7 ( B-SLICE, QP 40 ) 8960 bits [Y 28.6894 dB U 33.7796 dB V 34.3943 dB] [ET 77 ] [L0 6 5 4 3 ] [L1 6 5 4 3 ] [LC 6 5 4 3 ] [MD5:52b134c6e6029d664c689521858e77b0] POC 8 ( B-SLICE, QP 38 ) 45824 bits [Y 30.8462 dB U 34.7971 dB V 35.6495 dB] [ET 99 ] [L0 7 6 5 4 ] [L1 7 6 5 4 ] [LC 7 6 5 4 ] [MD5:770b71d9da2c4718de2a461293f8db93] POC 9 ( B-SLICE, QP 40 ) 7960 bits [Y 29.2780 dB U 34.3042 dB V 34.8880 dB] [ET 77 ] [L0 8 7 6 5 ] [L1 8 7 6 5 ] [LC 8 7 6 5 ] [MD5:45ee5f350e3cc5401f604e848f4c9b2a] POC 10 ( B-SLICE, QP 39 ) 12160 bits [Y 29.0234 dB U 34.0756 dB V 34.5376 dB] [ET 86 ] [L0 9 8 7 6 ] [L1 9 8 7 6 ] [LC 9 8 7 6 ] [MD5:08649aa321d313b07ac5c369379c1dc8] POC 11 ( B-SLICE, QP 40 ) 8968 bits [Y 28.5862 dB U 33.6277 dB V 34.0661 dB] [ET 84 ] [L0 10 9 8 7 ] [L1 10 9 8 7 ] [LC 10 9 8 7 ] [MD5:ff4cea0e95df9bba18f6d5bbbf39b7cf] POC 12 ( B-SLICE, QP 38 ) 46400 bits [Y 30.9894 dB U 34.9983 dB V 35.5133 dB] [ET 103 ] [L0 11 10 9 8 ] [L1 11 10 9 8 ] [LC 11 10 9 8 ] [MD5:3158dd666ea42a59fa0a3f3644ecced2] POC 13 ( B-SLICE, QP 40 ) 8384 bits [Y 29.3027 dB U 34.0683 dB V 34.5776 dB] [ET 82 ] [L0 12 11 10 9 ] [L1 12 11 10 9 ] [LC 12 11 10 9 ] [MD5:1b39e227b857290cf6e90f6ddaa7283a] POC 14 ( B-SLICE, QP 39 ) 11392 bits [Y 29.0517 dB U 33.8502 dB V 34.2562 dB] [ET 87 ] [L0 13 12 11 10 ] [L1 13 12 11 10 ] [LC 13 12 11 10 ] [MD5:fbd3c91fdb1ead4393cd20c1abfe1609] POC 15 ( B-SLICE, QP 40 ) 7904 bits [Y 28.5528 dB U 33.6226 dB V 33.9687 dB] [ET 83 ] [L0 14 13 12 11 ] [L1 14 13 12 11 ] [LC 14 13 12 11 ] [MD5:5a8575cf90a9dd6125f05e86ea3c7f45] POC 16 ( B-SLICE, QP 38 ) 45616 bits [Y 31.0864 dB U 34.7720 dB V 35.4715 dB] [ET 103 ] [L0 15 14 13 12 ] [L1 15 14 13 12 ] [LC 15 14 13 12 ] [MD5:1114f9fa88c1057401c98167dbff0525] POC 17 ( B-SLICE, QP 40 ) 6800 bits [Y 29.5958 dB U 34.1464 dB V 34.7726 dB] [ET 78 ] [L0 16 15 14 13 ] [L1 16 15 14 13 ] [LC 16 15 14 13 ] [MD5:e6091783fae709cafd84dcb1925367db] POC 18 ( B-SLICE, QP 39 ) 9576 bits [Y 29.3051 dB U 33.8528 dB V 34.4332 dB] [ET 85 ] [L0 17 16 15 14 ] [L1 17 16 15 14 ] [LC 17 16 15 14 ] [MD5:40f96440ac17a3ec28a340976bd5fbd0] POC 19 ( B-SLICE, QP 40 ) 8368 bits [Y 28.8664 dB U 33.7675 dB V 34.0675 dB] [ET 85 ] [L0 18 17 16 15 ] [L1 18 17 16 15 ] [LC 18 17 16 15 ] [MD5:739acc812b1ba7fb7396e6c2e607d1b3] POC 20 ( B-SLICE, QP 38 ) 43392 bits [Y 31.0118 dB U 34.8684 dB V 35.5475 dB] [ET 101 ] [L0 19 18 17 16 ] [L1 19 18 17 16 ] [LC 19 18 17 16 ] [MD5:4b0081ddf30c604dd67d2a953e4e9ea6] POC 21 ( B-SLICE, QP 40 ) 7144 bits [Y 29.2501 dB U 34.2950 dB V 34.7964 dB] [ET 78 ] [L0 20 19 18 17 ] [L1 20 19 18 17 ] [LC 20 19 18 17 ] [MD5:2fba944e4676565e6e9e506d70832d3c] POC 22 ( B-SLICE, QP 39 ) 9824 bits [Y 28.9308 dB U 34.2379 dB V 34.6044 dB] [ET 84 ] [L0 21 20 19 18 ] [L1 21 20 19 18 ] [LC 21 20 19 18 ] [MD5:bac70177bf1c37efb15597aada7a50aa] POC 23 ( B-SLICE, QP 40 ) 8336 bits [Y 28.4210 dB U 33.9740 dB V 34.1688 dB] [ET 81 ] [L0 22 21 20 19 ] [L1 22 21 20 19 ] [LC 22 21 20 19 ] [MD5:dd7c49da857af4402a59bef091b5cdf9] POC 24 ( B-SLICE, QP 38 ) 47456 bits [Y 30.5590 dB U 34.9500 dB V 35.3147 dB] [ET 101 ] [L0 23 22 21 20 ] [L1 23 22 21 20 ] [LC 23 22 21 20 ] [MD5:4e1412d456cd4f7d0c6ebd71dbadbd66] POC 25 ( B-SLICE, QP 40 ) 7704 bits [Y 29.1010 dB U 34.2810 dB V 34.3773 dB] [ET 78 ] [L0 24 23 22 21 ] [L1 24 23 22 21 ] [LC 24 23 22 21 ] [MD5:e2cf3f1ba4b8c71e0bc44c0053972953] POC 26 ( B-SLICE, QP 39 ) 10024 bits [Y 28.9158 dB U 34.2036 dB V 34.3524 dB] [ET 85 ] [L0 25 24 23 22 ] [L1 25 24 23 22 ] [LC 25 24 23 22 ] [MD5:3edd29d4a8bda3c1e618a1136f52fa2e] POC 27 ( B-SLICE, QP 40 ) 7912 bits [Y 28.3680 dB U 33.9745 dB V 33.9803 dB] [ET 80 ] [L0 26 25 24 23 ] [L1 26 25 24 23 ] [LC 26 25 24 23 ] [MD5:a6c740a43a4edbd7dd0dcbc0041910a1] POC 28 ( B-SLICE, QP 38 ) 46688 bits [Y 30.3667 dB U 35.0054 dB V 35.5154 dB] [ET 103 ] [L0 27 26 25 24 ] [L1 27 26 25 24 ] [LC 27 26 25 24 ] [MD5:2805671e94d15b9f50dc5c3851c7d09d] POC 29 ( B-SLICE, QP 40 ) 8680 bits [Y 28.5728 dB U 34.2633 dB V 34.6989 dB] [ET 83 ] [L0 28 27 26 25 ] [L1 28 27 26 25 ] [LC 28 27 26 25 ] [MD5:6c6025737b85350962d7a46c38ddddf5] POC 30 ( B-SLICE, QP 39 ) 11424 bits [Y 28.2662 dB U 34.1160 dB V 34.2897 dB] [ET 86 ] [L0 29 28 27 26 ] [L1 29 28 27 26 ] [LC 29 28 27 26 ] [MD5:58dac953b4bc7ef525693df0a282e342] POC 31 ( B-SLICE, QP 40 ) 8784 bits [Y 27.7873 dB U 33.8393 dB V 33.8690 dB] [ET 84 ] [L0 30 29 28 27 ] [L1 30 29 28 27 ] [LC 30 29 28 27 ] [MD5:f08de81ea00ad574232fa442aa5b27fb] POC 32 ( B-SLICE, QP 38 ) 52536 bits [Y 30.0289 dB U 34.8364 dB V 35.3832 dB] [ET 104 ] [L0 31 30 29 28 ] [L1 31 30 29 28 ] [LC 31 30 29 28 ] [MD5:77c44b6c1d61258a8750c1b120d6a073] POC 33 ( B-SLICE, QP 40 ) 7672 bits [Y 28.5818 dB U 34.2413 dB V 34.5546 dB] [ET 80 ] [L0 32 31 30 29 ] [L1 32 31 30 29 ] [LC 32 31 30 29 ] [MD5:f2f8cdb2a1f6233f6f59406376ded301] POC 34 ( B-SLICE, QP 39 ) 9152 bits [Y 28.2603 dB U 34.2063 dB V 34.5189 dB] [ET 82 ] [L0 33 32 31 30 ] [L1 33 32 31 30 ] [LC 33 32 31 30 ] [MD5:dbf87ba575505d4e2f1db62d7e094497] POC 35 ( B-SLICE, QP 40 ) 6520 bits [Y 28.0084 dB U 34.1842 dB V 34.2518 dB] [ET 74 ] [L0 34 33 32 31 ] [L1 34 33 32 31 ] [LC 34 33 32 31 ] [MD5:7411c883e698bb58f729c8d30926103c] POC 36 ( B-SLICE, QP 38 ) 44864 bits [Y 29.8705 dB U 35.1882 dB V 35.7169 dB] [ET 101 ] [L0 35 34 33 32 ] [L1 35 34 33 32 ] [LC 35 34 33 32 ] [MD5:6740e91ae4429e0596090e67bf8d0bce] POC 37 ( B-SLICE, QP 40 ) 5480 bits [Y 28.7769 dB U 34.9310 dB V 35.3164 dB] [ET 74 ] [L0 36 35 34 33 ] [L1 36 35 34 33 ] [LC 36 35 34 33 ] [MD5:46545f48ae1971ca8d554d5971d7d49c] POC 38 ( B-SLICE, QP 39 ) 7440 bits [Y 28.7549 dB U 34.8510 dB V 35.2282 dB] [ET 79 ] [L0 37 36 35 34 ] [L1 37 36 35 34 ] [LC 37 36 35 34 ] [MD5:5f800150a296026e87d50146fb683e9b] POC 39 ( B-SLICE, QP 40 ) 5696 bits [Y 28.3672 dB U 34.6452 dB V 34.7443 dB] [ET 75 ] [L0 38 37 36 35 ] [L1 38 37 36 35 ] [LC 38 37 36 35 ] [MD5:92e26eec5e5b5a27b1bdfa1328bcecd3] POC 40 ( B-SLICE, QP 38 ) 39248 bits [Y 29.9332 dB U 35.4217 dB V 36.0115 dB] [ET 98 ] [L0 39 38 37 36 ] [L1 39 38 37 36 ] [LC 39 38 37 36 ] [MD5:641add5119004019c367211024885c43] POC 41 ( B-SLICE, QP 40 ) 6400 bits [Y 28.6213 dB U 35.0453 dB V 34.9926 dB] [ET 73 ] [L0 40 39 38 37 ] [L1 40 39 38 37 ] [LC 40 39 38 37 ] [MD5:27ea8f33bac0a98598ab88ba58191e3c] POC 42 ( B-SLICE, QP 39 ) 9152 bits [Y 28.4618 dB U 34.3669 dB V 34.8004 dB] [ET 79 ] [L0 41 40 39 38 ] [L1 41 40 39 38 ] [LC 41 40 39 38 ] [MD5:d8f1a696dbb1eae308ce2640c455e560] POC 43 ( B-SLICE, QP 40 ) 7704 bits [Y 28.1025 dB U 34.3138 dB V 34.7747 dB] [ET 80 ] [L0 42 41 40 39 ] [L1 42 41 40 39 ] [LC 42 41 40 39 ] [MD5:bbb56162b394fa68fb52247597350289] POC 44 ( B-SLICE, QP 38 ) 40936 bits [Y 29.9250 dB U 35.2542 dB V 36.0721 dB] [ET 100 ] [L0 43 42 41 40 ] [L1 43 42 41 40 ] [LC 43 42 41 40 ] [MD5:b9b0900fd05fd56b24f9f1bc2e804e12] POC 45 ( B-SLICE, QP 40 ) 7200 bits [Y 28.5237 dB U 34.5929 dB V 35.1694 dB] [ET 73 ] [L0 44 43 42 41 ] [L1 44 43 42 41 ] [LC 44 43 42 41 ] [MD5:c966e30cde48617d596e5f5ca79cb6dd] POC 46 ( B-SLICE, QP 39 ) 9616 bits [Y 28.3345 dB U 34.3793 dB V 34.8260 dB] [ET 79 ] [L0 45 44 43 42 ] [L1 45 44 43 42 ] [LC 45 44 43 42 ] [MD5:434bce84f519e1b521adc6ab5162087a] POC 47 ( B-SLICE, QP 40 ) 7792 bits [Y 27.8900 dB U 34.1555 dB V 34.4490 dB] [ET 77 ] [L0 46 45 44 43 ] [L1 46 45 44 43 ] [LC 46 45 44 43 ] [MD5:7d6caa07a505b9694b9b90956a48ece7] POC 48 ( B-SLICE, QP 38 ) 48608 bits [Y 30.0177 dB U 35.0982 dB V 35.7372 dB] [ET 99 ] [L0 47 46 45 44 ] [L1 47 46 45 44 ] [LC 47 46 45 44 ] [MD5:1da31cbe73aaff57c136060e09c3482f] POC 49 ( B-SLICE, QP 40 ) 7360 bits [Y 28.7304 dB U 34.7328 dB V 35.0491 dB] [ET 79 ] [L0 48 47 46 45 ] [L1 48 47 46 45 ] [LC 48 47 46 45 ] [MD5:82b20a1ae77425097aa88fbbb6f2f1b8] POC 50 ( B-SLICE, QP 39 ) 9464 bits [Y 28.6961 dB U 34.4936 dB V 34.9101 dB] [ET 83 ] [L0 49 48 47 46 ] [L1 49 48 47 46 ] [LC 49 48 47 46 ] [MD5:eb8ba1031ba35870bf29f74b71347645] POC 51 ( B-SLICE, QP 40 ) 7360 bits [Y 28.2627 dB U 34.0909 dB V 34.5555 dB] [ET 81 ] [L0 50 49 48 47 ] [L1 50 49 48 47 ] [LC 50 49 48 47 ] [MD5:db5a178ad5fae1451cc8f9ff5c2e59b8] POC 52 ( B-SLICE, QP 38 ) 41072 bits [Y 30.4147 dB U 35.2364 dB V 35.8372 dB] [ET 103 ] [L0 51 50 49 48 ] [L1 51 50 49 48 ] [LC 51 50 49 48 ] [MD5:6f06fb65828299c49910c3195600ca9b] POC 53 ( B-SLICE, QP 40 ) 7104 bits [Y 29.0416 dB U 34.7865 dB V 35.3478 dB] [ET 80 ] [L0 52 51 50 49 ] [L1 52 51 50 49 ] [LC 52 51 50 49 ] [MD5:2d22b5ca20cbf9c37728c4161988b688] POC 54 ( B-SLICE, QP 39 ) 9704 bits [Y 28.8377 dB U 34.7619 dB V 35.0506 dB] [ET 83 ] [L0 53 52 51 50 ] [L1 53 52 51 50 ] [LC 53 52 51 50 ] [MD5:1d5f4f3124b9823f2e2dcc365e0b57f0] POC 55 ( B-SLICE, QP 40 ) 8720 bits [Y 28.4988 dB U 34.3196 dB V 34.4240 dB] [ET 82 ] [L0 54 53 52 51 ] [L1 54 53 52 51 ] [LC 54 53 52 51 ] [MD5:493e43cc6753c898c4d16ec01ba8062e] POC 56 ( B-SLICE, QP 38 ) 47936 bits [Y 30.7977 dB U 35.2858 dB V 35.7857 dB] [ET 104 ] [L0 55 54 53 52 ] [L1 55 54 53 52 ] [LC 55 54 53 52 ] [MD5:fd6941535a37c6ec419812be2c7d2d5a] POC 57 ( B-SLICE, QP 40 ) 7016 bits [Y 29.2005 dB U 34.8853 dB V 35.2498 dB] [ET 80 ] [L0 56 55 54 53 ] [L1 56 55 54 53 ] [LC 56 55 54 53 ] [MD5:fdf7cdabdac46b6fc589e6bba2fc9bac] POC 58 ( B-SLICE, QP 39 ) 10240 bits [Y 29.1207 dB U 34.7613 dB V 34.7928 dB] [ET 83 ] [L0 57 56 55 54 ] [L1 57 56 55 54 ] [LC 57 56 55 54 ] [MD5:6b5f2d0a167051a7d9568ba7a2b1fd4b] POC 59 ( B-SLICE, QP 40 ) 8016 bits [Y 28.7076 dB U 34.6926 dB V 34.6709 dB] [ET 83 ] [L0 58 57 56 55 ] [L1 58 57 56 55 ] [LC 58 57 56 55 ] [MD5:f3e40b50d7db0c7d2cb90f11e7314e56] SUMMARY -------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 60 a 567.3720 29.2114 34.4934 34.9526 I Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 1 i 3610.3200 31.9047 35.5105 36.6706 P Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 0 p -1.#IND -1.#IND -1.#IND -1.#IND B Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 59 b 515.7966 29.1658 34.4762 34.9234 RVM: 1.571 Total Time: 4997.279 sec. Decoding: HM software: Decoder Version [3.0][Windows][VS 1500][32 bit] POC 0 ( I-SLICE, QP 37 ) [DT 0.062] [L0 ] [L1 ] [MD5:27d35840064a53ff746e342fe7ab8198,(OK)] POC 1 ( B-SLICE, QP 40 ) [DT 0.015] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:6917ca1fc8e3e1d7516e22a78f64a6bc,(OK)] POC 2 ( B-SLICE, QP 39 ) [DT 0.015] [L0 1 0 ] [L1 1 0 ] [LC 1 0 ] [MD5:4e3a93c981e7b579ff1516510b16ac3c,(OK)] POC 3 ( B-SLICE, QP 40 ) [DT 0.031] [L0 2 1 0 ] [L1 2 1 0 ] [LC 2 1 0 ] [MD5:b2f2d6231a16d342c28fa51334bf055b,(OK)] POC 4 ( B-SLICE, QP 38 ) [DT 0.047] [L0 3 2 1 0 ] [L1 3 2 1 0 ] [LC 3 2 1 0 ] [MD5:9e022e223488e6eb0b134caba9acf75c,(OK)] POC 5 ( B-SLICE, QP 40 ) [DT 0.016] [L0 4 3 2 1 ] [L1 4 3 2 1 ] [LC 4 3 2 1 ] [MD5:f6f946003b5da492a460be1d14090d0c,(OK)] POC 6 ( B-SLICE, QP 39 ) [DT 0.016] [L0 5 4 3 2 ] [L1 5 4 3 2 ] [LC 5 4 3 2 ] [MD5:7e79fa528a780e58f43ee935388b889c,(OK)] POC 7 ( B-SLICE, QP 40 ) [DT 0.015] [L0 6 5 4 3 ] [L1 6 5 4 3 ] [LC 6 5 4 3 ] [MD5:52b134c6e6029d664c689521858e77b0,(OK)] POC 8 ( B-SLICE, QP 38 ) [DT 0.047] [L0 7 6 5 4 ] [L1 7 6 5 4 ] [LC 7 6 5 4 ] [MD5:770b71d9da2c4718de2a461293f8db93,(OK)] POC 9 ( B-SLICE, QP 40 ) [DT 0.016] [L0 8 7 6 5 ] [L1 8 7 6 5 ] [LC 8 7 6 5 ] [MD5:45ee5f350e3cc5401f604e848f4c9b2a,(OK)] POC 10 ( B-SLICE, QP 39 ) [DT 0.016] [L0 9 8 7 6 ] [L1 9 8 7 6 ] [LC 9 8 7 6 ] [MD5:08649aa321d313b07ac5c369379c1dc8,(OK)] POC 11 ( B-SLICE, QP 40 ) [DT 0.015] [L0 10 9 8 7 ] [L1 10 9 8 7 ] [LC 10 9 8 7 ] [MD5:ff4cea0e95df9bba18f6d5bbbf39b7cf,(OK)] POC 12 ( B-SLICE, QP 38 ) [DT 0.031] [L0 11 10 9 8 ] [L1 11 10 9 8 ] [LC 11 10 9 8 ] [MD5:3158dd666ea42a59fa0a3f3644ecced2,(OK)] POC 13 ( B-SLICE, QP 40 ) [DT 0.015] [L0 12 11 10 9 ] [L1 12 11 10 9 ] [LC 12 11 10 9 ] [MD5:1b39e227b857290cf6e90f6ddaa7283a,(OK)] POC 14 ( B-SLICE, QP 39 ) [DT 0.032] [L0 13 12 11 10 ] [L1 13 12 11 10 ] [LC 13 12 11 10 ] [MD5:fbd3c91fdb1ead4393cd20c1abfe1609,(OK)] POC 15 ( B-SLICE, QP 40 ) [DT 0.031] [L0 14 13 12 11 ] [L1 14 13 12 11 ] [LC 14 13 12 11 ] [MD5:5a8575cf90a9dd6125f05e86ea3c7f45,(OK)] POC 16 ( B-SLICE, QP 38 ) [DT 0.047] [L0 15 14 13 12 ] [L1 15 14 13 12 ] [LC 15 14 13 12 ] [MD5:1114f9fa88c1057401c98167dbff0525,(OK)] POC 17 ( B-SLICE, QP 40 ) [DT 0.016] [L0 16 15 14 13 ] [L1 16 15 14 13 ] [LC 16 15 14 13 ] [MD5:e6091783fae709cafd84dcb1925367db,(OK)] POC 18 ( B-SLICE, QP 39 ) [DT 0.015] [L0 17 16 15 14 ] [L1 17 16 15 14 ] [LC 17 16 15 14 ] [MD5:40f96440ac17a3ec28a340976bd5fbd0,(OK)] POC 19 ( B-SLICE, QP 40 ) [DT 0.032] [L0 18 17 16 15 ] [L1 18 17 16 15 ] [LC 18 17 16 15 ] [MD5:739acc812b1ba7fb7396e6c2e607d1b3,(OK)] POC 20 ( B-SLICE, QP 38 ) [DT 0.047] [L0 19 18 17 16 ] [L1 19 18 17 16 ] [LC 19 18 17 16 ] [MD5:4b0081ddf30c604dd67d2a953e4e9ea6,(OK)] POC 21 ( B-SLICE, QP 40 ) [DT 0.016] [L0 20 19 18 17 ] [L1 20 19 18 17 ] [LC 20 19 18 17 ] [MD5:2fba944e4676565e6e9e506d70832d3c,(OK)] POC 22 ( B-SLICE, QP 39 ) [DT 0.032] [L0 21 20 19 18 ] [L1 21 20 19 18 ] [LC 21 20 19 18 ] [MD5:bac70177bf1c37efb15597aada7a50aa,(OK)] POC 23 ( B-SLICE, QP 40 ) [DT 0.016] [L0 22 21 20 19 ] [L1 22 21 20 19 ] [LC 22 21 20 19 ] [MD5:dd7c49da857af4402a59bef091b5cdf9,(OK)] POC 24 ( B-SLICE, QP 38 ) [DT 0.047] [L0 23 22 21 20 ] [L1 23 22 21 20 ] [LC 23 22 21 20 ] [MD5:4e1412d456cd4f7d0c6ebd71dbadbd66,(OK)] POC 25 ( B-SLICE, QP 40 ) [DT 0.016] [L0 24 23 22 21 ] [L1 24 23 22 21 ] [LC 24 23 22 21 ] [MD5:e2cf3f1ba4b8c71e0bc44c0053972953,(OK)] POC 26 ( B-SLICE, QP 39 ) [DT 0.031] [L0 25 24 23 22 ] [L1 25 24 23 22 ] [LC 25 24 23 22 ] [MD5:3edd29d4a8bda3c1e618a1136f52fa2e,(OK)] POC 27 ( B-SLICE, QP 40 ) [DT 0.015] [L0 26 25 24 23 ] [L1 26 25 24 23 ] [LC 26 25 24 23 ] [MD5:a6c740a43a4edbd7dd0dcbc0041910a1,(OK)] POC 28 ( B-SLICE, QP 38 ) [DT 0.047] [L0 27 26 25 24 ] [L1 27 26 25 24 ] [LC 27 26 25 24 ] [MD5:2805671e94d15b9f50dc5c3851c7d09d,(OK)] POC 29 ( B-SLICE, QP 40 ) [DT 0.031] [L0 28 27 26 25 ] [L1 28 27 26 25 ] [LC 28 27 26 25 ] [MD5:6c6025737b85350962d7a46c38ddddf5,(OK)] POC 30 ( B-SLICE, QP 39 ) [DT 0.016] [L0 29 28 27 26 ] [L1 29 28 27 26 ] [LC 29 28 27 26 ] [MD5:58dac953b4bc7ef525693df0a282e342,(OK)] POC 31 ( B-SLICE, QP 40 ) [DT 0.016] [L0 30 29 28 27 ] [L1 30 29 28 27 ] [LC 30 29 28 27 ] [MD5:f08de81ea00ad574232fa442aa5b27fb,(OK)] POC 32 ( B-SLICE, QP 38 ) [DT 0.047] [L0 31 30 29 28 ] [L1 31 30 29 28 ] [LC 31 30 29 28 ] [MD5:77c44b6c1d61258a8750c1b120d6a073,(OK)] POC 33 ( B-SLICE, QP 40 ) [DT 0.031] [L0 32 31 30 29 ] [L1 32 31 30 29 ] [LC 32 31 30 29 ] [MD5:f2f8cdb2a1f6233f6f59406376ded301,(OK)] POC 34 ( B-SLICE, QP 39 ) [DT 0.031] [L0 33 32 31 30 ] [L1 33 32 31 30 ] [LC 33 32 31 30 ] [MD5:dbf87ba575505d4e2f1db62d7e094497,(OK)] POC 35 ( B-SLICE, QP 40 ) [DT 0.016] [L0 34 33 32 31 ] [L1 34 33 32 31 ] [LC 34 33 32 31 ] [MD5:7411c883e698bb58f729c8d30926103c,(OK)] POC 36 ( B-SLICE, QP 38 ) [DT 0.032] [L0 35 34 33 32 ] [L1 35 34 33 32 ] [LC 35 34 33 32 ] [MD5:6740e91ae4429e0596090e67bf8d0bce,(OK)] POC 37 ( B-SLICE, QP 40 ) [DT 0.016] [L0 36 35 34 33 ] [L1 36 35 34 33 ] [LC 36 35 34 33 ] [MD5:46545f48ae1971ca8d554d5971d7d49c,(OK)] POC 38 ( B-SLICE, QP 39 ) [DT 0.031] [L0 37 36 35 34 ] [L1 37 36 35 34 ] [LC 37 36 35 34 ] [MD5:5f800150a296026e87d50146fb683e9b,(OK)] POC 39 ( B-SLICE, QP 40 ) [DT 0.016] [L0 38 37 36 35 ] [L1 38 37 36 35 ] [LC 38 37 36 35 ] [MD5:92e26eec5e5b5a27b1bdfa1328bcecd3,(OK)] POC 40 ( B-SLICE, QP 38 ) [DT 0.047] [L0 39 38 37 36 ] [L1 39 38 37 36 ] [LC 39 38 37 36 ] [MD5:88f93ccd83a025c5bc709b6f49de1dcc,(***ERROR***)] [rxMD5:641add5119004019c367211024885c43] POC 41 ( B-SLICE, QP 40 ) [DT 0.031] [L0 40 39 38 37 ] [L1 40 39 38 37 ] [LC 40 39 38 37 ] [MD5:4f86751e7006fb90f97cad96a6b9f7c2,(***ERROR***)] [rxMD5:27ea8f33bac0a98598ab88ba58191e3c] POC 42 ( B-SLICE, QP 39 ) [DT 0.000] [L0 41 40 39 38 ] [L1 41 40 39 38 ] [LC 41 40 39 38 ] [MD5:d7b04d62502866890328fca34ee8b5bc,(***ERROR***)] [rxMD5:d8f1a696dbb1eae308ce2640c455e560] POC 43 ( B-SLICE, QP 40 ) [DT 0.031] [L0 42 41 40 39 ] [L1 42 41 40 39 ] [LC 42 41 40 39 ] [MD5:5101392e3ded50fad876b51de044b1f1,(***ERROR***)] [rxMD5:bbb56162b394fa68fb52247597350289] POC 44 ( B-SLICE, QP 38 ) [DT 0.046] [L0 43 42 41 40 ] [L1 43 42 41 40 ] [LC 43 42 41 40 ] [MD5:8c1ae2e131f203857e9bc090f411cfb3,(***ERROR***)] [rxMD5:b9b0900fd05fd56b24f9f1bc2e804e12] POC 45 ( B-SLICE, QP 40 ) [DT 0.016] [L0 44 43 42 41 ] [L1 44 43 42 41 ] [LC 44 43 42 41 ] [MD5:e98a584251e90b6185e4556b8e8860b9,(***ERROR***)] [rxMD5:c966e30cde48617d596e5f5ca79cb6dd] POC 46 ( B-SLICE, QP 39 ) [DT 0.015] [L0 45 44 43 42 ] [L1 45 44 43 42 ] [LC 45 44 43 42 ] [MD5:87876a0f15f75ee02881f8879cc8c379,(***ERROR***)] [rxMD5:434bce84f519e1b521adc6ab5162087a] POC 47 ( B-SLICE, QP 40 ) [DT 0.016] [L0 46 45 44 43 ] [L1 46 45 44 43 ] [LC 46 45 44 43 ] [MD5:fcefa1eb30d3934bdacbf3eab598ae49,(***ERROR***)] [rxMD5:7d6caa07a505b9694b9b90956a48ece7] POC 48 ( B-SLICE, QP 38 ) [DT 0.046] [L0 47 46 45 44 ] [L1 47 46 45 44 ] [LC 47 46 45 44 ] [MD5:b8ad945e80eab08d8358ca20be620ba6,(***ERROR***)] [rxMD5:1da31cbe73aaff57c136060e09c3482f] POC 49 ( B-SLICE, QP 40 ) [DT 0.016] [L0 48 47 46 45 ] [L1 48 47 46 45 ] [LC 48 47 46 45 ] [MD5:0d471b31e285f7d249a13dc1c80b3ad9,(***ERROR***)] [rxMD5:82b20a1ae77425097aa88fbbb6f2f1b8] POC 50 ( B-SLICE, QP 39 ) [DT 0.015] [L0 49 48 47 46 ] [L1 49 48 47 46 ] [LC 49 48 47 46 ] [MD5:f8674fa26758720e0cdd843530757e29,(***ERROR***)] [rxMD5:eb8ba1031ba35870bf29f74b71347645] POC 51 ( B-SLICE, QP 40 ) [DT 0.016] [L0 50 49 48 47 ] [L1 50 49 48 47 ] [LC 50 49 48 47 ] [MD5:261ac2d68a0b025a57b2e42cdb4b2e7f,(***ERROR***)] [rxMD5:db5a178ad5fae1451cc8f9ff5c2e59b8] POC 52 ( B-SLICE, QP 38 ) [DT 0.031] [L0 51 50 49 48 ] [L1 51 50 49 48 ] [LC 51 50 49 48 ] [MD5:fa8ba341f309b4e144e5cee49879df35,(***ERROR***)] [rxMD5:6f06fb65828299c49910c3195600ca9b] POC 53 ( B-SLICE, QP 40 ) [DT 0.016] [L0 52 51 50 49 ] [L1 52 51 50 49 ] [LC 52 51 50 49 ] [MD5:11eb00136a9e93715381ec8edf686640,(***ERROR***)] [rxMD5:2d22b5ca20cbf9c37728c4161988b688] POC 54 ( B-SLICE, QP 39 ) [DT 0.031] [L0 53 52 51 50 ] [L1 53 52 51 50 ] [LC 53 52 51 50 ] [MD5:2b41e444cf0848db01a3355624fe8ff8,(***ERROR***)] [rxMD5:1d5f4f3124b9823f2e2dcc365e0b57f0] POC 55 ( B-SLICE, QP 40 ) [DT 0.031] [L0 54 53 52 51 ] [L1 54 53 52 51 ] [LC 54 53 52 51 ] [MD5:043e7f5fd518c4dab41e2b4d7ec3feb3,(***ERROR***)] [rxMD5:493e43cc6753c898c4d16ec01ba8062e] POC 56 ( B-SLICE, QP 38 ) [DT 0.047] [L0 55 54 53 52 ] [L1 55 54 53 52 ] [LC 55 54 53 52 ] [MD5:acb13bc727805a9f5647d7fa922cee58,(***ERROR***)] [rxMD5:fd6941535a37c6ec419812be2c7d2d5a] POC 57 ( B-SLICE, QP 40 ) [DT 0.015] [L0 56 55 54 53 ] [L1 56 55 54 53 ] [LC 56 55 54 53 ] [MD5:fdf7cdabdac46b6fc589e6bba2fc9bac,(OK)] POC 58 ( B-SLICE, QP 39 ) [DT 0.016] [L0 57 56 55 54 ] [L1 57 56 55 54 ] [LC 57 56 55 54 ] [MD5:6b5f2d0a167051a7d9568ba7a2b1fd4b,(OK)] POC 59 ( B-SLICE, QP 40 ) [DT 0.031] [L0 58 57 56 55 ] [L1 58 57 56 55 ] [LC 58 57 56 55 ] [MD5:f3e40b50d7db0c7d2cb90f11e7314e56,(OK)] ***ERROR*** A decoding mismatch occured: signalled md5sum does not match Total Time: 2.249 sec. Mismatches were also observed for some other sequences under lowdelay and/or randomaccess settings. " wangj HM-3.0 143 (E049) When ALF off and SAO on, setUseNonCrossAlf(flag) is not set before calling ALF process HM HM-3.0 defect closed 2011-04-15T20:25:50+02:00 2011-05-17T20:14:15+02:00 "Using revision r804 In TEncGop.cpp:385, setting of non-cross-ALF is guarded by ALF being in use: {{{ if(pcSlice->getSPS()->getUseALF()) { ... } }}} Later, however, at around line 509: {{{ #if MTK_SAO if ( pcSlice->getSPS()->getUseALF() || (pcSlice->getSPS()->getUseSAO()) ) ... m_pcAdaptiveLoopFilter->startALFEnc(pcPic, m_pcEntropyCoder ); }}} The ALF process is called without the correct state being set. " davidf HM-3.0 151 Decoding mismatch/crash when RDOQ off HM HM-3.0 defect closed 2011-04-25T11:20:49+02:00 2011-04-28T18:04:56+02:00 "Decoding mismatch/crash was observed when RDOQ off (HM3.0). For example for BasketballPass_416x240_50.yuv, QP=32, 9 frames, decoding mismatch occurs. The encoding and decoding logs are as follows. Encoding: HM software: Encoder Version [3.0][Windows][VS 1500][32 bit] Input File : E:\Sequences\JCTVC_Seqs\D01_BasketballPass_416x240_50.yuv Bitstream File : str\HM2.0_IntraLoCo_D01_BasketballPass_416x240_QP32.bin Reconstruction File : yuv\HM2.0_IntraLoCo_D01_BasketballPass_416x240_QP32.rec Real Format : 416x240 50Hz Internal Format : 416x240 50Hz Frame index : 0 - 8 (9 frames) Number of Ref. frames (P) : 4 Number of Ref. frames (B_L0) : 2 Number of Ref. frames (B_L1) : 2 Number of Reference frames : 4 CU size / depth : 64 / 4 RQT trans. size (min / max) : 4 / 32 Max RQT depth inter : 3 Max RQT depth intra : 3 Motion search range : 64 Intra period : -1 Decoding refresh type : 0 QP : 32.00 GOP size : 1 Rate GOP size : 4 Internal bit depth : 8 Entropy coder : VLC TOOL CFG: ALF:0 IBD:0 HAD:1 SRD:0 RDQ:0 SQP:0 ASR:0 PAD:0 LDC:1 NRF:0 BQP:1 GPB:1 LComb:1 LCMod:0 FEN:1 RQT:1 MRG:1 LMC:1 Slice:0 EntropySlice:0 CIP:0 SAO:1 POC 0 ( I-SLICE, QP 32 ) 39776 bits [Y 35.7291 dB U 39.5039 dB V 39.3209 dB] [ET 1 ] [L0 ] [L1 ] [MD5:d9a6ef5e818feaa199a227af58784ca6] POC 1 ( B-SLICE, QP 35 ) 1520 bits [Y 34.3308 dB U 39.2839 dB V 38.5440 dB] [ET 1 ] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:b3df8c513e3209a0b14307c9d9ea09b1] POC 2 ( B-SLICE, QP 34 ) 2712 bits [Y 34.1265 dB U 39.1618 dB V 38.3636 dB] [ET 2 ] [L0 1 0 ] [L1 1 0 ] [LC 1 0 ] [MD5:c880ad3d1cb40000b4082b53f250265a] POC 3 ( B-SLICE, QP 35 ) 2144 bits [Y 33.6282 dB U 38.9792 dB V 37.9861 dB] [ET 2 ] [L0 2 1 0 ] [L1 2 1 0 ] [LC 2 1 0 ] [MD5:2d270756a661bef00b4d560a65e05786] POC 4 ( B-SLICE, QP 33 ) 8544 bits [Y 35.1661 dB U 39.2272 dB V 38.8317 dB] [ET 3 ] [L0 3 2 1 0 ] [L1 3 2 1 0 ] [LC 3 2 1 0 ] [MD5:3cff5217f5e8a583aa2ff81cc8eec5ae] POC 5 ( B-SLICE, QP 35 ) 1208 bits [Y 34.1652 dB U 39.0674 dB V 38.6094 dB] [ET 3 ] [L0 4 3 2 1 ] [L1 4 3 2 1 ] [LC 4 3 2 1 ] [MD5:a7475351d7b8d45d96915216386435ec] POC 6 ( B-SLICE, QP 34 ) 2472 bits [Y 33.9374 dB U 38.9547 dB V 38.1424 dB] [ET 3 ] [L0 5 4 3 2 ] [L1 5 4 3 2 ] [LC 5 4 3 2 ] [MD5:d4eb37372ad5e4e08a25bfe27c138125] POC 7 ( B-SLICE, QP 35 ) 2080 bits [Y 33.5086 dB U 38.7835 dB V 37.7761 dB] [ET 3 ] [L0 6 5 4 3 ] [L1 6 5 4 3 ] [LC 6 5 4 3 ] [MD5:8ac93966370d07fe738631dc62842e43] POC 8 ( B-SLICE, QP 33 ) 9008 bits [Y 35.0873 dB U 39.2397 dB V 38.9473 dB] [ET 3 ] [L0 7 6 5 4 ] [L1 7 6 5 4 ] [LC 7 6 5 4 ] [MD5:7083472bb2123aa971a996e3fcfd2ddb] SUMMARY -------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 9 a 385.9111 34.4088 39.1335 38.5024 I Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 1 i 1988.8000 35.7291 39.5039 39.3209 P Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 0 p -1.#IND -1.#IND -1.#IND -1.#IND B Slices-------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 8 b 185.5500 34.2437 39.0872 38.4001 RVM: 0.000 Total Time: 18.750 sec. Decoding: HM software: Decoder Version [3.0][Windows][VS 1500][32 bit] POC 0 ( I-SLICE, QP 32 ) [DT 0.015] [L0 ] [L1 ] [MD5:d9a6ef5e818feaa199a227af58784ca6,(OK)] POC 1 ( B-SLICE, QP 35 ) [DT 0.016] [L0 0 ] [L1 0 ] [LC 0 ] [MD5:b3df8c513e3209a0b14307c9d9ea09b1,(OK)] POC 2 ( B-SLICE, QP 34 ) [DT 0.000] [L0 1 0 ] [L1 1 0 ] [LC 1 0 ] [MD5:c880ad3d1cb40000b4082b53f250265a,(OK)] POC 3 ( B-SLICE, QP 35 ) [DT 0.000] [L0 2 1 0 ] [L1 2 1 0 ] [LC 2 1 0 ] [MD5:2d270756a661bef00b4d560a65e05786,(OK)] POC 4 ( B-SLICE, QP 33 ) [DT 0.000] [L0 3 2 1 0 ] [L1 3 2 1 0 ] [LC 3 2 1 0 ] [MD5:3cff5217f5e8a583aa2ff81cc8eec5ae,(OK)] POC 5 ( B-SLICE, QP 35 ) [DT 0.000] [L0 4 3 2 1 ] [L1 4 3 2 1 ] [LC 4 3 2 1 ] [MD5:a7475351d7b8d45d96915216386435ec,(OK)] POC 6 ( B-SLICE, QP 34 ) [DT 0.016] [L0 5 4 3 2 ] [L1 5 4 3 2 ] [LC 5 4 3 2 ] [MD5:d4eb37372ad5e4e08a25bfe27c138125,(OK)] POC 7 ( B-SLICE, QP 35 ) [DT 0.000] [L0 6 5 4 3 ] [L1 6 5 4 3 ] [LC 6 5 4 3 ] [MD5:9fa944844475f06d77ad1fbbbff687d3,(***ERROR***)] [rxMD5:8ac93966370d07fe738631dc62842e43] POC 8 ( B-SLICE, QP 33 ) [DT 0.000] [L0 7 6 5 4 ] [L1 7 6 5 4 ] [LC 7 6 5 4 ] [MD5:415f4387d617f0381f9eef090665b6c5,(***ERROR***)] [rxMD5:7083472bb2123aa971a996e3fcfd2ddb] ***ERROR*** A decoding mismatch occured: signalled md5sum does not match Total Time: 0.078 sec. Sometimes, decoding crash was also observed. So far, the bug has not been located. Fortunately, this bug does not affect behavior under common conditions." Xiang Li HM-3.0 178 corrupted heap / assert failed for QuadtreeTULog2MinSize: 4 HM HM-3.0 defect closed 2011-05-30T16:44:28+02:00 2014-01-11T20:27:15+01:00 "I found erroe related to ticket#168 in HM3.0 so I modified the (TEncAdaptiveLoopFilter.cpp, TEncAdaptiveLoopFilter.h) files as suggested by Chih-Ming in jct-vc Digest, Vol 16, Issue 66, but now I am getting error of corrupted heap , I tried to run this on other computers but they are also giving the same error chih-ming suggested it is the bug associate with TComPicSym::destroy()function. I found the error in the memory allocation." satyam_iitd HM-3.0 197 SAO defect: HM encoder crash for over-12bit encoding HM HM-3.0 defect closed 2011-08-12T05:47:07+02:00 2014-01-11T20:28:46+01:00 "HM encoder (at least of version 3.0 or higher) crashes when over-12bit sequence is input. Example: TAppEncoder -c cfg/encoder_intra_loco.cfg -c cfg/per-sequence/BQSquare_416x240_60.cfg --InternalBitDepth=14 When SAO is disabled, it works. TAppEncoder -c cfg/encoder_intra_loco.cfg -c cfg/per-sequence/BQSquare_416x240_60.cfg --InternalBitDepth=14 --SAO=0 " hao HM-3.0 144 decoder crashes on empty input file HM HM-3.0 defect davidf closed 2011-04-15T22:03:43+02:00 2011-05-12T17:45:54+02:00 "performing: {{{ $ rm out.bit; touch out.bit $ ./jctvc-tmuc-dec --BitstreamFile=out.bit }}} causes: {{{ ==13135== Use of uninitialised value of size 8 ==13135== at 0x428A7A: TComPic::getPicSym() (TComPic.h:78) ==13135== by 0x466B72: TDecTop::executeDeblockAndAlf(bool, TComBitstream*, unsigned int&, TComList*&, int&, int&) (TDecTop.cpp:183) ==13135== by 0x4051E5: TAppDecTop::decode() (TAppDecTop.cpp:119) ==13135== by 0x402B0F: main (decmain.cpp:76) ==13135== ==13135== ==13135== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n ==13135== Invalid read of size 8 ==13135== at 0x40598D: TComPicSym::getSlice(unsigned int) (TComPicSym.h:78) ==13135== by 0x466B7C: TDecTop::executeDeblockAndAlf(bool, TComBitstream*, unsigned int&, TComList*&, int&, int&) (TDecTop.cpp:183) ==13135== by 0x4051E5: TAppDecTop::decode() (TAppDecTop.cpp:119) ==13135== by 0x402B0F: main (decmain.cpp:76) ==13135== Address 0x9691aa5 is not stack'd, malloc'd or (recently) free'd ==13135== ==13135== ==13135== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n ==13135== ==13135== Process terminating with default action of signal 11 (SIGSEGV) ==13135== Access not within mapped region at address 0x9691AA5 ==13135== at 0x40598D: TComPicSym::getSlice(unsigned int) (TComPicSym.h:78) ==13135== by 0x466B7C: TDecTop::executeDeblockAndAlf(bool, TComBitstream*, unsigned int&, TComList*&, int&, int&) (TDecTop.cpp:183) ==13135== by 0x4051E5: TAppDecTop::decode() (TAppDecTop.cpp:119) ==13135== by 0x402B0F: main (decmain.cpp:76) }}}" davidf HM-3.0 146 Bug in HM3.0 in the implementation of spatial mvp scaling. HM HM-3.0 defect closed 2011-04-19T20:10:29+02:00 2011-04-22T16:10:42+02:00 "Bug in HM3.0 in the implementation of spatial mvp scaling. In TComDataCU::fillMvpCand() around line #2893: if(!bAdded) { bAdded = xAddMVPCand( pInfo, eRefPicList, iRefIdx, uiPartIdxLT, MD_ABOVE_LEFT); if (bAdded && pInfo->iN==2 && pInfo->m_acMvCand[0] == pInfo->m_acMvCand[1]) { pInfo->iN--; //remove duplicate entries bAdded = false; <--- This line should be added } } Without this statement, bAdded remains true although mv is not added to the list. Therefore, MTK_AMVP_SMVP_DERIVATION code is not performed in this case. " madhukar HM-3.0 147 bug related to UNIFY_INTER_TABLE HM HM-3.0 defect closed 2011-04-20T04:27:17+02:00 2011-04-22T16:11:58+02:00 "In TEncCavlc::codeInterDir around line 1333, if (m_pcSlice->getNoBackPredFlag()) { '''uiMaxVal''' = uiValNumRefIdxOfL0 + iRefFrame0*uiValNumRefIdxOfL1 + iRefFrame1; // In my opinion, it should be '''uiIndex''' } else { uiIndex = uiValNumRefIdxOfL0 + uiValNumRefIdxOfL1 + iRefFrame0*uiValNumRefIdxOfL1 + iRefFrame1; }" libin HM-3.0 148 Fix RBSP emulation HM HM-3.0 defect davidf closed 2011-04-20T21:43:47+02:00 2011-05-16T19:43:21+02:00 "The HM encoder currently fails to perform startcode emulation prevention on all NAL units. Worse, the current method of doing this has lead to some horrible hacks to signal where slices start so that the anti-emulation code can skip over the startcodes. A solution is to assemble separate NALunits (this also allows for trivial reordering of the NALunits in cases where SEI messages are calculated after the picture has been encoded) and deal with them as a vector (much like writev(2))." davidf HM-3.0 149 Warning in E-243 Matrix Multiplication HM HM-3.0 defect davidf closed 2011-04-22T01:29:11+02:00 2011-04-22T16:07:28+02:00 In HM 3.0, when setting Macro for Matrix Multiplication to 1 for E-243 Core Transforms, there are warnings. On Linux platform, this results in HM 3.0 code to not compile. asaxena HM-3.0 150 Default value in LM chroma HM HM-3.0 defect closed 2011-04-22T10:55:27+02:00 2011-05-30T01:04:42+02:00 "In the function xGetLLSPrediction default value is calculated as b = 128 << g_uiBitIncrement; assuming that input bit depth is 8, but should be b = ( 1 << ( g_uiBitDepth + g_uiBitIncrement - 1 ) );" Vadim HM-3.0 154 CHANGE_GET_MERGE_CANDIDATE macro used inconsistently HM HM-3.0 defect closed 2011-04-28T17:19:16+02:00 2011-04-28T17:21:23+02:00 Macro CHANGE_GET_MERGE_CANDIDATE is not used in TEncEntropy::encodeMergeFlag, making that function not symmetric with TDecEntropy::decodeMergeFlag. Use of the macro should thus be added in TEncEntropy::encodeMergeFlag. fbossen HM-3.0 156 luma-based chroma intra prediction with CIP, reference_pixel_padding consideration HM HM-3.0 defect closed 2011-04-29T08:15:04+02:00 2011-05-17T20:19:38+02:00 "In current HM3.0, luma-based chroma intra prediction is integrated without consideration of CIP, reference_pixel_paddin and slice boundary. A modified software will be uploaded. In common test configuration, performance effect of this modication is less than 0.01% for Luma BDrate and less than 0.1% for chroma BDrate." jlchen HM-3.0 157 FIXED_ROUNDING_FRAME_MEMORY modifies output picture rather than reference picture HM HM-3.0 defect davidf closed 2011-04-29T18:03:10+02:00 2012-11-05T22:57:41+01:00 "In TEncGOP.cpp: {{{ xCalculateAddPSNR( pcPic, pcPic->getPicYuvRec(), numBits, dEncTime ); #if FIXED_ROUNDING_FRAME_MEMORY pcPic->getPicYuvRec()->xFixedRoundingPic(); #endif ... pcPic->getPicYuvRec()->copyToPic(pcPicYuvRecOut); }}} xFixedRoundingPic() causes both the output picture and any reference picture to be modified. xFixedRoundingPic() in the encoder should be performed after {{{ pcPic->getPicYuvRec()->copyToPic(pcPicYuvRecOut);}}}. In the decoder, a similar change is required, however, the decoder does not currently have a separate reorder buffer." davidf HM-3.0 158 build failure with -DDCM_SKIP_DECODING_FRAMES=0 HM HM-3.0 defect closed 2011-04-29T18:11:06+02:00 2011-05-17T20:16:55+02:00 "Disabling the DCM_SKIP_DECODING_FRAMES macro causes errors: {{{ TAppDecTop.cpp: In member function ‘Void TAppDecTop::decode()’: TAppDecTop.cpp:118: error: ‘m_iSkipFrame’ was not declared in this scope TAppDecTop.cpp:119: error: ‘m_iSkipFrame’ was not declared in this scope TDecTop.cpp: In member function ‘Void TDecTop::decode(Bool, TComBitstream*, UInt&, TComList*&)’: TDecTop.cpp:242: error: return-statement with a value, in function returning 'void' TDecTop.cpp:247: error: return-statement with a value, in function returning 'void' TDecTop.cpp:252: error: return-statement with a value, in function returning 'void' TDecTop.cpp:287: error: return-statement with a value, in function returning 'void' TDecTop.cpp:437: error: return-statement with a value, in function returning 'void' }}} " davidf HM-3.0 159 Bitrate calculation: Byte count mismatch HM HM-3.0 defect davidf closed 2011-05-02T17:22:47+02:00 2011-05-21T23:21:30+02:00 The bitstream file size does not match the reported bitrate because the bytes for the SPS and PPS are not considered in the bitrate calculation of HM3.0. mwi HM-3.0 160 (E049) SAO bug in SAO_EO_2 boundary HM HM-3.0 defect closed 2011-05-06T08:42:41+02:00 2011-05-17T20:18:24+02:00 "Using revision r858 In TEncAdaptiveLoopFilter.cpp: 5270, the variable iSignDown2: {{{ iSignDown2 = xSign(pRec[iStride] - pRec[0]); }}} should be as follows {{{ iSignDown2 = xSign(pRec[iStride+1] - pRec[0]); }}} This bug is related to SAO_EO_2 (one type of SAO) in the LCU boundary. This modification make the meaning of SAO_EO_2 in the LCU boundary consistent with the rest of the LCU region. The BD-rate will improve about 0.01%." chihming.fu HM-3.0 165 Bug in update of Golomb-Rice parameter in TComTrQuant::xRateDistOptQuant function HM HM-3.0 defect closed 2011-05-19T00:23:45+02:00 2011-05-20T00:11:08+02:00 "There is a bug in the update of Golomb-Rice parameter in the RDOQ function for CABAC. The following buggy code occurs twice inside the function '''if( uiAbs > 3 )''' { '''uiAbs -= 4;''' uiAbs = min( uiAbs, 15 ); uiGoRiceParam = g_aauiGoRiceUpdate[ uiGoRiceParam ][ uiAbs ]; } and should be replaced with '''if( uiAbs > 2 )''' { '''uiAbs -= 3;''' uiAbs = min( uiAbs, 15 ); uiGoRiceParam = g_aauiGoRiceUpdate[ uiGoRiceParam ][ uiAbs ]; } However, the impact on coding efficiency by this bug fix appears to be negligible when tested on 49 frames. The corresponding excel sheet is attached." sandeepkanumuri HM-3.0 167 JCTVC-E049 bugs about pixel maximum value of SAO output and the memory allocation of CABAC encoder HM HM-3.0 defect closed 2011-05-20T08:22:12+02:00 2011-08-17T09:01:22+02:00 "Using revision r928 In TComAdaptiveLoopFilter.cpp:2885, the maximun value of SAO output is {{{ UInt uiMaxY = 255 << g_uiBitIncrement; }}} The maximum value of SAO should use the variable consistent with the other part of HM-3.0 as following {{{ UInt uiMaxY = g_uiIBDI_MAX; }}} In TEncTop.cpp:143, the variable g_uiMaxCUDepth is used to allocate the memory of variable m_pppcRDSbacCoder; however, SAO will re-use the variable m_pppcRDSbacCoder and therefore, the memory allocation process of pppcRDSbacCoder need set variable g_uiMaxCUDepth to 4 temporary." chihming.fu HM-3.0 168 JCTVC-E049 bug about the CABAC memory allocation for SAO HM HM-3.0 defect closed 2011-05-23T09:19:21+02:00 2011-08-17T09:27:38+02:00 "Using revision r929 In TEncAdaptiveLoopFilter.cpp:4984, add variables for SAO encoder without using global variable m_pppcRDSbacCoder. {{{ Int iMaxDepth = 4; m_pppcRDSbacCoder = new TEncSbac** [iMaxDepth+1]; m_pppcBinCoderCABAC = new TEncBinCABAC** [iMaxDepth+1]; for ( Int iDepth = 0; iDepth < iMaxDepth+1; iDepth++ ) { m_pppcRDSbacCoder[iDepth] = new TEncSbac* [CI_NUM]; m_pppcBinCoderCABAC[iDepth] = new TEncBinCABAC* [CI_NUM]; for (Int iCIIdx = 0; iCIIdx < CI_NUM; iCIIdx ++ ) { m_pppcRDSbacCoder[iDepth][iCIIdx] = new TEncSbac; m_pppcBinCoderCABAC [iDepth][iCIIdx] = new TEncBinCABAC; m_pppcRDSbacCoder [iDepth][iCIIdx]->init( m_pppcBinCoderCABAC [iDepth][iCIIdx] ); } } }}} Also, these variables should be deleted in function destoryEncBuffer(). " chihming.fu HM-3.0 169 C++ typedef bug HM HM-3.0 defect closed 2011-05-24T05:07:01+02:00 2011-08-17T09:17:56+02:00 "The TypeDef.h file typedefs void to Void. This is a potential source for future bugs as the C++ standard will not allow using Void in function arguments. This bug can be seen when trying to compile the HM-2.0-ahg-memory branch with a standards compliant C++ compiler like g++" chiraag HM-3.0 174 MVP index bits not accounted for when comparing candidates in xCheckBestMVP HM HM-3.0 defect closed 2011-05-29T15:43:56+02:00 2011-08-17T08:43:34+02:00 "In function `TEncSearch::xCheckBestMVP`, when checking the cost of each available MV predictor, the cost of signalling the index (specified in the array `m_auiMVPIdxCost`) is not taken into account. The results with the fix applied, based on 24 pictures and obtained with `HM-3.0-dev` are as follows: {{{ Random access Random access LoCo Y U V Y U V Class A 0.0 -0.2 -0.2 0.0 -0.1 -0.1 Class B 0.0 0.0 -0.2 -0.1 -0.1 -0.1 Class C 0.0 -0.1 0.2 0.0 0.0 -0.1 Class D -0.1 -0.2 -0.2 -0.1 0.1 -0.2 Class E All 0.0 -0.1 -0.1 0.0 0.0 -0.1 Low delay Low delay LoCo Y U V Y U V Class A Class B -0.1 -0.2 0.0 0.0 0.1 0.1 Class C 0.0 0.3 0.2 0.0 0.2 0.2 Class D 0.0 -0.1 0.4 -0.1 -0.3 -0.1 Class E -0.1 -0.2 -0.3 0.0 0.2 0.1 All 0.0 0.0 0.1 0.0 0.0 0.0 Low delay (P) Low delay LC (P) Y U V Y U V Class A Class B 0.0 0.3 0.3 0.0 -0.1 -0.1 Class C 0.0 -0.1 -0.1 0.0 -0.1 -0.1 Class D -0.2 0.1 0.1 0.0 0.1 0.1 Class E -0.1 -0.4 -0.4 0.0 0.4 0.4 All -0.1 -0.1 -0.1 0.0 0.0 0.0 }}} " nsprljan HM-3.0 181 Improper motion information subsampling HM HM-3.0 defect closed 2011-06-01T19:22:42+02:00 2011-08-17T08:44:30+02:00 "In TComCUMvField::compress subsampling of motion information is done using a constant factor AMVP_DECIMATION_FACTOR. When the smallest CU size is other than 8x8 (and smallest PU size other than 4x4) this leads to a subsampling that may be more substantial than intended. For example if the smallest CU size is 16x16, motion vectors would be kept at 32x32 resolution. Additionally if the maximum CU depth is 1 this leads to memory corruption as it is not possible to subsample by a factor of 4 (default value of AMVP_DECIMATION_FACTOR) without crossing LCU boundaries. " fbossen HM-3.0 191 setting FULL_NBIT macro to 1 breaks the encoder HM HM-3.0 defect closed 2011-07-07T03:55:39+02:00 2011-08-17T08:50:43+02:00 Setting FULL_NBIT macro to 1 breaks the encoder. There are several recently added or modified code that uses g_uiBitIncrement by itself and not in conjunction with g_uiBitDepth. This type of code breaks when FULL_NBIT macro is set to 1. dthoang HM-3.0 155 No Cbf check while doing intra inverse transform HM HM-3.0 enhancement closed 2011-04-29T07:59:29+02:00 2014-01-11T20:24:47+01:00 "There is no check for Cbf in xIntraRecLumaBlk and xIntraRecChromaBlk functions while doing inverse transform and reconstruction" Vadim HM-3.0 176 Code duplication in TEncSbac::codeCoeffNxN HM HM-3.0 enhancement closed 2011-05-30T02:15:01+02:00 2011-08-17T08:53:17+02:00 Splitting the coding of bins for levels and sign into separate bin planes has resulted in some code duplication. This can be improved. fbossen HM-3.0 153 Strange code in TDecTop::executeDeblockAndAlf() HM HM-3.0 defect davidf closed 2011-04-28T07:41:58+02:00 2011-05-21T23:21:22+02:00 "In TDecTop::executeDeblockAndAlf(), a variable pcSlice is defined as follows. {{{ TComSlice* pcSlice = pcPic->getPicSym()->getSlice( m_uiSliceIdx ); }}} The variable pcSlice always points non-existent Slice object, since m_uiSliceIdx is the last valid Slice index minus 1 when executeDeblockAndAlf() is called. pcSlice is used for calling the member function sortPicList() but this usage is meaningless because sortPicList() is defined as a static function. Therefore, pcSlice should be removed and the description {{{ pcSlice->sortPicList( m_cListPic ); }}} should be replaced with {{{ TComSlice::sortPicList( m_cListPic ); }}} Similar description is also found in TDecTop::xGetNewPicBuffer()." hao HM-3.0 164 Violations of style guide section 3.2.2 (opening brace) HM HM-3.0 defect closed 2011-05-18T17:15:04+02:00 2011-05-22T01:05:54+02:00 "3.2.2. '''The opening brace is placed on a new line on the same indentation level as the defining keyword''' (e.g. void, if, for, while, etc.). The included code block starts at the following line and is indented. The closing brace is placed on the same indentation level as the opening brace. HM-3.0-dev r925 {{{ Find all ""[A-Za-z\(\)] *\{(^\})*$"", Regular expressions, Subfolders, Find Results 1, ""Entire Solution"" [...] Matching lines: 141 Matching files: 21 Total files searched: 116 }}} HM-3.0 (r823) {{{ Matching lines: 128 Matching files: 16 Total files searched: 110 }}} HM 2.0 (r572): {{{ Matching lines: 117 Matching files: 9 Total files searched: 103 }}}" ksuehring HM-3.0 170 uiPOC uninitialized HM HM-3.0 defect closed 2011-05-24T05:31:03+02:00 2011-05-24T15:00:29+02:00 "This is a minor bug with the state of uiPOC in TAppDecTop.cpp The variable is unitialized and causes it to go out of state after the first frame is decoded. Initializing it to -1 is a temporary fix as the value is no longer an unsigned integer but doing so keeps it in order with the frame just decoded as seen later" chiraag HM-16.9 1495 decoder bug about HEVC encryption HM HM-16.9 defect new 2018-08-07T15:02:08+02:00 2018-08-07T15:02:08+02:00 "when encrypt the video by HM 16.9,An error occurred. I encrypt the merge index by encoder.the code are as follow Void TEncSbac::codeMergeIndex( TComDataCU* pcCU, UInt uiAbsPartIdx ) { UInt uiUnaryIdx = pcCU->getMergeIndex( uiAbsPartIdx ); Int Key_Mergeidx=0; for(int i = 0;i< 2;i++) { if(num4 >7999) num4 = 0; if(keyArr[num4++]) Key_Mergeidx+=1<<(2-i-1); } uiUnaryIdx=(uiUnaryIdx+Key_Mergeidx)%5; and then I decrypt it by decoder via the codes below Int Key_Mergeidx=0; for(int i = 0;i< 2;i++) { if(num4 >7999) num4 = 0; if(keyArr[num4++]) Key_Mergeidx+=1<<(2-i-1); } uiUnaryIdx=(uiUnaryIdx+5-Key_Mergeidx)%5; the yuv sequence I get is a little different from the version which just encode and then decode. Actually I just change the merge index to a number between 0 and 4 at encoder,and it is reversible, but after decode and decrypt, in some frames, a little pixels are not the same as the version which just encode and then decode.can you tell why? thank you very much!,it is definitely important for me to solve this problem. " martin_zx HM-16.9 1447 Leftover TEMPORAL_SUBSAMPLE macro HM HM-16.9 defect closed 2016-03-23T23:30:40+01:00 2016-11-22T19:14:48+01:00 TEMPORAL_SUBSAMPLE macro in TEncGOP.cpp is leftover probably after cleaning the code for temporal subsampling, since the macro is not defined the code is not active. Macro should be removed. Vadim HM-16.9 1450 HM encoder memory reduction HM HM-16.9 enhancement closed 2016-05-13T17:56:55+02:00 2016-05-25T18:53:12+02:00 "The HM Encoder takes excessive memory, especially when considering increasing picture sizes and GOP structures. For example, when encoding Traffic (2560x1600), with the 16-frame GOP structure used by JVET, memory requirements are 2482 MiB. For 4K sequences, memory requirements are approximately 2.1 times higher; i.e. ~ 5361 MiB. For derived branches, such as JEM, memory utilization is even higher. The reason is because all memory is allocated for all the processing at the outset. This means that for a 16 frame GOP simulation, up to 32 TComPic objects will be present, all of which have memory allocated for encoding decisions. 15 of the frames will only actually contain source image data - these are frames that have been buffered up prior to the complete GOP encoding. 1 of the frames will be being processed, and will therefore need source data and encoding decision data. Up to 16 frames will be kept as part of the reference picture list structure. These technically only require the reconstructed picture data and other information present in the DPB. The attached patch reduced the memory usage by ~60% for the above example, reducing Traffic, GOP-16 from 2482 MiB to just 1020 MiB. It achieves this by allocating memory only when it is needed. It also introduces a DPB structure into which side information is placed for reference frame usage. Note that there is not such a significant problem in the decoder, as it only allocates data for pictures when they are decoded, and destroys the data afterwards (as it also has to cope with video format changes). The patch does not affect run-time or coding efficiency. I have uploaded it as a ticket so that other branches may examine and comment. " karlsharman HM-16.8 1443 extra condition on reading of loop_filter_across_tiles_enabled_flag HM HM-16.8 enhancement closed 2016-03-11T12:25:52+01:00 2016-11-22T19:14:48+01:00 "(on behalf of Pavel Evsikov pavel.evsikov@intel.com) In parsePPS, there is if ((tileColumnsMinus1 + tileRowsMinus1) != 0) { READ_FLAG ( uiCode, ""loop_filter_across_tiles_enabled_flag"" ); pcPPS->setLoopFilterAcrossTilesEnabledFlag( uiCode ? true : false ); } Though (tileColumnsMinus1 + tileRowsMinus1) != 0 is a conformance condition, the spec does not tell that reading of the flag is possible only when both reading parameters are not zeros. The It is better to user ""assert"" for the conformance condition." kolya HM-16.8 1444 orphaned line HM HM-16.8 enhancement closed 2016-03-13T16:56:17+01:00 2016-11-22T18:37:14+01:00 "In TEncGOP.cpp, line 1407 pcPic->getSlice(pcSlice->getSliceIdx())->setMvdL1ZeroFlag(pcSlice->getMvdL1ZeroFlag()); this line does nothing" kolya HM-16.8 1446 naming mismatch HM HM-16.8 enhancement closed 2016-03-22T18:27:36+01:00 2016-11-22T19:14:48+01:00 "scalability_mask -> scalability_mask_flag all_ref_layers_active_flag -> default_ref_layers_active_flag sps_strong_intra_smoothing_enable_flag -> strong_intra_smoothing_enabled_flag transquant_bypass_enable_flag -> transquant_bypass_enabled_flag sps_temporal_mvp_enable_flag -> sps_temporal_mvp_enabled_flag sign_data_hiding_flag -> sign_data_hiding_enabled_flag pps_disable_deblocking_filter_flag -> pps_deblocking_filter_disabled_flag slice_disable_deblocking_filter_flag -> slice_deblocking_filter_disabled_flag" kolya HM-16.7 1430 TComPicYuv.cpp possible memory leak HM HM-16.7 enhancement closed 2015-10-23T17:38:02+02:00 2016-02-20T03:49:48+01:00 "It is possible to set to NULL valid pointer in HM-16.7. It seems it is better to check if they points to allocated memory. See the patch attached. " kolya HM-16.7 1445 CMake for HM HM HM-16.7 enhancement closed 2016-03-21T14:53:07+01:00 2023-01-05T17:57:17+01:00 "Hi, I created a CMake configuration file for HM. You can find it attached. Create a folder named HM-dir/build/cmake and put it there. I also attached a short script (for Linux) which is meant to be run from the same directory and will build both debug and release configuration. I hope you will find this helpful and include it in future releases. CMake makes it easy to build configuration for a wide variety of systems. I only tested the generation of Unix makefiles for Linux, but other platforms should work as well." jsauer HM-16.5 1407 HM cannot compile with VS 2015 HM HM-16.5 defect closed 2015-07-27T10:46:59+02:00 2016-04-12T16:16:38+02:00 HM cannot compile with VS 2015. Removing compat\msvc\stdint.h can solve the problem. libin HM-16.5 1410 Memory leak in TEncGOP::xCreatePictureTimingSEI HM HM-16.5 defect closed 2015-08-05T19:19:43+02:00 2016-04-12T16:18:00+02:00 "{{{ SEIPictureTiming *pictureTimingSEI = new SEIPictureTiming(); }}} The object is created, however it is used conditionally later on, so then condition is false memory seems not freed. Attached patch may solve the problem." Vadim HM-16.5 1429 cfg_DisplayPrimariesCode fix HM HM-16.5 defect closed 2015-10-22T13:03:57+02:00 2016-02-20T03:50:25+01:00 "Issue reported in JCTVC-V0063 and m37008 is fixed but attached patch. An example of cfg file suitable for proper encoding MPEG's HDR&WCG CfE materials is attached." lenchik HM-16.5 1397 extra variable HM HM-16.5 enhancement closed 2015-05-28T15:47:35+02:00 2015-06-12T19:21:10+02:00 "In TEncCu.cpp line 818: UInt uiTargetPartIdx = 0; this variable is always zero, so there is no need to arrange a variable." kolya HM-16.5 1414 orphaned variables HM HM-16.5 enhancement closed 2015-09-11T10:32:48+02:00 2015-09-14T10:50:13+02:00 "line 262 of TEncSearch.cpp both of these variables do nothing m_puiDFilter = s_auiDFilter + 4;" kolya HM-16.5 1399 line to remove HM HM-16.5 enhancement closed 2015-06-01T21:01:41+02:00 2015-06-12T19:21:10+02:00 "TAppEncCfg.cpp line 1486 has uiAddCUDepth++; that is never used later." kolya HM-16.5 1400 bad destructor HM HM-16.5 enhancement closed 2015-06-05T16:24:47+02:00 2015-06-12T19:20:05+02:00 "~TEncSearch() contains deleting of memory that was arranged in init function, not in a constructor. It would be better to match clearing memory in a kind of ""destroy"" function, as it was done in many places in code." kolya HM-16.5 1406 duplicate lines HM HM-16.5 enhancement closed 2015-07-21T21:16:41+02:00 2016-04-12T16:18:43+02:00 "line 234 of TDecEntropy.cpp duplicates line 219 uiMergeIndex = pcCU->getMergeIndex( uiSubPartIdx ); " kolya HM-16.5 1408 tautology HM HM-16.5 enhancement closed 2015-07-28T16:27:54+02:00 2016-04-12T16:18:57+02:00 "it seems lines 332 and 333 of TComSlice.cpp m_aiNumRefIdx[REF_PIC_LIST_0] = getNumRefIdx(REF_PIC_LIST_0); m_aiNumRefIdx[REF_PIC_LIST_1] = getNumRefIdx(REF_PIC_LIST_1); do nothing" kolya HM-16.5 1409 TComScalingList improvement HM HM-16.5 enhancement closed 2015-08-02T23:20:12+02:00 2015-08-04T17:46:02+02:00 Dear colleagues, me faced with the need to re-use code of TComScalingList class and me found that some of its methods like getScalingListAddress return a pointer to the first element in a vector. But all they fail when size of an arranged vector is zero. In other words, one cannot use these methods without prior constructor call. It seems this may be refactored. kolya HM-16.4 1382 HM16.4: calls to printSummary are missing a parameter HM HM-16.4 defect closed 2015-03-10T14:45:55+01:00 2015-03-10T17:37:27+01:00 "Calls to the printSummary function are missing the ""bitDepths"" parameter. Attached patch fixes the issue (that is present only if _SUMMARY_OUT_ or _SUMMARY_PIC_ are defined). BTW, the HM16.4 option is not yet present in the bug tracker." jani.lainema HM-16.4 1383 Profile/Tier/Level checks needed at encoder HM HM-16.4 defect new 2015-03-12T17:35:47+01:00 2015-03-12T17:35:47+01:00 "When Profile/Tier/Level are specified, the encoder should constrain configuration settings in a way, that bitstreams are generated, which conform to the given PTL setting. It has been reported, that intra-only profiles are not restricted to IRAP pictures. Please file other missing checks under this ticket. (Ticket is related to #1367 which refers to bitstream checking at the decoder)" ksuehring HM-16.4 1389 possible memory issue HM HM-16.4 defect closed 2015-04-14T15:35:59+02:00 2016-04-12T16:20:14+02:00 It seems (I am not sure) that in TDecCU::create (TDecCu.cpp line 82) there is wrong loop condition: it should be <= rather that <, coz when m_uiMaxDepth == 1 there is no memory allocation. kolya HM-16.4 1392 ARM cross-compilation issues with g++/Linux HM HM-16.4 defect closed 2015-04-20T14:51:28+02:00 2015-08-12T16:50:44+02:00 "The following code has been added to address issue #206 {{{ #!cpp #ifdef __arm__ typedef signed char Char; #else typedef char Char; #endif }}} It has been reported that defining Char to ""signed char"" created compilation issues in related to I/O functions in TVideoIOYuv.cpp/.h. These can be addressed by removing the special case for ARM in typedef.h There may still exist arithmetic problems with signed vs. unsigned calculations (as reported in #206)." ksuehring HM-16.4 1393 Unnecessary condition checking when handling no output of prior picture HM HM-16.4 defect new 2015-04-28T02:26:00+02:00 2015-04-28T02:26:00+02:00 "There is the following checking within function checkNoOutputPriorPics ""if (m_lastPOCNoOutputPriorPics != pcPicTmp->getPOC())"" This checking is unnecessary and cause a bug for the following cases: Suppose that original bitstream coded with random access structure with IDR at every 32 pictures and the second IDR has its value of no_output_of_prior_pics_flag equal to 1. Then all other non-IDR pictures is removed from the bitstream leaving the bitstream. It is expected that when decoder shall not output the first IDR because after the first IDR has been decoded (and gets into the DPB) it will be flushed without outputting it because the next IDR has no_output_of_prior_pics_flag equal to 1. However, because of the above checking, decoder will not mark the first IDR as not to output because its POC is the same as the POC of the second IDR. Simply removing that condition would fix the bug. Patch for this removal is attached." fhendry HM-16.4 1394 m_LocalRPS is not reset between CVSs, resulting in incorrect long term reference picture count HM HM-16.4 defect closed 2015-05-07T14:45:10+02:00 2015-05-08T15:15:19+02:00 "In TDecCavlc::parseSliceHeader() (TDecCAVLC.cpp line 1070), the number of long term reference pictures is set in the RPS if sps->getLongTermRefsPresent() == true. However, the number of long term reference pictures is not set to zero if sps->getLongTermRefsPresent() == false; in this case, it is just left at its previous value. This causes a bug when there is more than one CVS present in the stream. If the first CVS uses an SPS with long_term_ref_pics_present_flag = 1, and the second uses one with long_term_ref_pics_present_flag = 0, the long term reference picture count will not get reset between CVSs, resulting in an error. Suggested fix is to reset the contents of TComSlice::m_LocalRPS in TComSlice::initSlice()." jackh HM-16.4 1385 The symbol is not defined HM HM-16.4 defect closed 2015-03-26T16:09:26+01:00 2015-03-27T12:54:38+01:00 "Hi A definition for the symbol 'DEBUG_INTRA_SEARCH_COSTS' could not be found in Tencsearch.cpp :: line 2297 #ifdef DEBUG_INTRA_SEARCH_COSTS std::cout << ""1st pass mode "" << uiMode << "" SAD = "" << uiSad << "", mode bits = "" << iModeBits << "", cost = "" << cost << ""\n""; #endif" m0hammadreza HM-16.3 1379 Inferred TU splitting flag in RDO. HM HM-16.3 defect karlsharman closed 2015-03-01T07:14:01+01:00 2015-03-25T13:08:14+01:00 The inferred TU splitting flag is not taken into consideration in the RDO process. The attached patch may solve the problem. libin HM-16.3 1380 m_callerOwnsSEIs is not initialized HM HM-16.3 defect closed 2015-03-05T02:47:04+01:00 2015-03-05T13:34:56+01:00 "m_callerOwnsSEIs (SEI.h, line 487) is not initialized for SEIScalableNesting, however it is used in the destructor. It can be fixed as the following: {{{ SEIScalableNesting() : m_callerOwnsSEIs(false) {} }}}" Vadim HM-16.3 1387 documentation of bWriteMode parameter to TVideoIOYuv::open() is incorrect HM HM-16.3 defect closed 2015-04-10T03:08:58+02:00 2015-04-13T12:22:37+02:00 "In the documentation of TVideoIOYuv::open(), {{{ * \param bWriteMode file open mode: true=read, false=write }}} should be {{{ * \param bWriteMode file open mode: true=write, false=read }}} " dthoang HM-16.3 1377 strange code HM HM-16.3 enhancement closed 2015-02-20T21:12:50+01:00 2015-03-04T20:26:29+01:00 "In TAppDecTop.cpp line 126 there is while (!!bitstreamFile) Is double ""!!"" really better than while (bitstreamFile) ?" kolya HM-16.3 1381 Useless Assert in TComRdCost HM HM-16.3 enhancement karlsharman closed 2015-03-06T15:09:48+01:00 2015-03-23T20:31:39+01:00 "In the method TComRdCost::xGetComponentBits, it would seem to me that it is impossible for the value of uiTemp to be zero. I think the ""assert ( uiTemp );"" is useless. " LucTrudeau HM-16.2 1346 wrong STSA decision HM HM-16.2 defect new 2014-10-30T09:19:42+01:00 2014-10-30T09:27:09+01:00 "In HEVC specification, STSA is noted as in below: ''Pictures following an STSA picture in decoding order with the same TemporalId as the STSA picture do not use picture prior to the STSA picture in decoding order with the same TemporalId as the STSA picture for inter prediction reference. '' However, TEncGop.cpp decides nal_unit_type as STSA when STSA is not used for reference for pictures following an STSA picture in decoding order with the same TemporalId as the STA picture. (as shown in below) {{{ Bool isSTSA=true; for(Int ii=iGOPid+1;(iigetGOPSize() && isSTSA==true);ii++) { Int lTid= m_pcCfg->getGOPEntry(ii).m_temporalId; if(lTid==pcSlice->getTLayer()) { TComReferencePictureSet* nRPS = pcSlice->getSPS()->getRPSList()->getReferencePictureSet(ii); for(Int jj=0;jjgetNumberOfPictures();jj++) { if(nRPS->getUsed(jj)) { Int tPoc=m_pcCfg->getGOPEntry(ii).m_POC+nRPS->getDeltaPOC(jj); Int kk=0; for(kk=0;kkgetGOPSize();kk++) { if(m_pcCfg->getGOPEntry(kk).m_POC==tPoc) break; } Int tTid=m_pcCfg->getGOPEntry(kk).m_temporalId; if(tTid >= pcSlice->getTLayer()) { isSTSA=false; break; } } } } }}} I made a quick patch for this bug, and confirmed it working. {{{ Index: Lib/TLibEncoder/TEncGOP.cpp =================================================================== --- Lib/TLibEncoder/TEncGOP.cpp (revision 4178) +++ Lib/TLibEncoder/TEncGOP.cpp (working copy) @@ -910,23 +910,20 @@ if(lTid==pcSlice->getTLayer()) { TComReferencePictureSet* nRPS = pcSlice->getSPS()->getRPSList()->getReferencePictureSet(ii); - for(Int jj=0;jjgetNumberOfPictures();jj++) + for(Int jj=0;(jjgetNumberOfPictures() && isSTSA==true);jj++) { if(nRPS->getUsed(jj)) { Int tPoc=m_pcCfg->getGOPEntry(ii).m_POC+nRPS->getDeltaPOC(jj); Int kk=0; - for(kk=0;kkgetGOPSize();kk++) + for(kk=0;kkgetGOPEntry(kk).m_POC==tPoc) + { + isSTSA=false; break; + } } - Int tTid=m_pcCfg->getGOPEntry(kk).m_temporalId; - if(tTid >= pcSlice->getTLayer()) - { - isSTSA=false; - break; - } } } } }}} " tee.jung HM-16.2 1349 HM cannot decode the 1st buffering period SEI message. HM HM-16.2 defect karlsharman closed 2014-11-12T20:22:40+01:00 2015-03-25T17:23:36+01:00 "We found that current HM trunk cannot correctly decode the buffering period SEI message coded along with the 1st IDR picture. The code can be fixed as following: '''After Fix:''' {{{ Void TDecTop::xDecodeSEI( TComInputBitstream* bs, const NalUnitType nalUnitType ) { //HUA_FIX: the 1st buffering period SEI cannot be correctly decoded if w/o the following fix. TComSPS* sps = m_parameterSetManagerDecoder.getActiveSPS(); if(sps == NULL) { sps = m_parameterSetManagerDecoder.getPrefetchedSPS(0); } if(nalUnitType == NAL_UNIT_SUFFIX_SEI) { m_seiReader.parseSEImessage( bs, m_pcPic->getSEIs(), nalUnitType, sps, m_pDecodedSEIOutputStream ); } else { m_seiReader.parseSEImessage( bs, m_SEIs, nalUnitType, sps, m_pDecodedSEIOutputStream ); SEIMessages activeParamSets = getSeisByType(m_SEIs, SEI::ACTIVE_PARAMETER_SETS); if (activeParamSets.size()>0) { SEIActiveParameterSets *seiAps = (SEIActiveParameterSets*)(*activeParamSets.begin()); m_parameterSetManagerDecoder.applyPrefetchedPS(); assert(seiAps->activeSeqParameterSetId.size()>0); if (! m_parameterSetManagerDecoder.activateSPSWithSEI(seiAps->activeSeqParameterSetId[0] )) { printf (""Warning SPS activation with Active parameter set SEI failed""); } } } } }}} '''Before Fix:''' {{{ Void TDecTop::xDecodeSEI( TComInputBitstream* bs, const NalUnitType nalUnitType ) { if(nalUnitType == NAL_UNIT_SUFFIX_SEI) { m_seiReader.parseSEImessage( bs, m_pcPic->getSEIs(), nalUnitType, m_parameterSetManagerDecoder.getActiveSPS(), m_pDecodedSEIOutputStream ); } else { m_seiReader.parseSEImessage( bs, m_SEIs, nalUnitType, m_parameterSetManagerDecoder.getActiveSPS(), m_pDecodedSEIOutputStream ); SEIMessages activeParamSets = getSeisByType(m_SEIs, SEI::ACTIVE_PARAMETER_SETS); if (activeParamSets.size()>0) { SEIActiveParameterSets *seiAps = (SEIActiveParameterSets*)(*activeParamSets.begin()); m_parameterSetManagerDecoder.applyPrefetchedPS(); assert(seiAps->activeSeqParameterSetId.size()>0); if (! m_parameterSetManagerDecoder.activateSPSWithSEI(seiAps->activeSeqParameterSetId[0] )) { printf (""Warning SPS activation with Active parameter set SEI failed""); } } } } }}} Note that this may not be the best way to fix the issue. But it does help to avoid the decoder crash and allow it to correctly decode the bitstream." gaow02 HM-16.2 1366 Cross component prediction should be done only in 4:4:4 chroma HM HM-16.2 defect closed 2015-01-29T16:11:21+01:00 2015-01-29T16:52:58+01:00 "Check for chroma format is absent in TDecSbac::parseCrossComponentPrediction. This makes it possible to turn cross component prediction in profiles that don't support it. Specification doesn't require cross_component_prediction_enabled_flag to be 0 even in main and main10 profiles. Attached is a patch that adds this check." gregory HM-16.2 1371 reserved_zero_43bits[32..42] written using 12 bits instead of 11 bits HM HM-16.2 defect closed 2015-02-04T06:06:15+01:00 2015-02-04T12:35:12+01:00 "Revision 4252 of HM-dev introduced a serious bug that can be fixed as follows. In TEncCavlc::codeProfileTier(), the following line {{{ WRITE_CODE(0x000 , 12, PTL_TRACE_TEXT(""reserved_zero_43bits[32..42]"" )); }}} should be changed to {{{ WRITE_CODE(0x000 , 11, PTL_TRACE_TEXT(""reserved_zero_43bits[32..42]"" )); }}} This is a serious issue and generates bitstreams that cause the HM decoder to crash. " dthoang HM-16.2 1343 HM should stop on unknown parameters HM HM-16.2 enhancement closed 2014-10-27T19:17:31+01:00 2015-03-04T20:13:56+01:00 "It has been requested that the HM encoder should fail when it encounters an unknown parameter. The advantage is that when parameters get changed or renamed, old configuration files will fail instead of running with unexpected defaults. HM currently only issues a warning." ksuehring HM-16.2 1320 Range of values in residual modification process HM HM-16.2 defect closed 2014-09-08T12:35:50+02:00 2014-11-14T16:24:19+01:00 "I wonder if there should be some limit on the values generated by the residual modification process? At the moment there does not appear to be any constraint, so if cu_transquant_bypass_flag is equal to 1, equation 8-267 allows r[x][y] to be as large as CoeffMax (2^15^ -1 for Main 4:4:4 10). The residual modification process 8-6-5 then computes a cumulative sum of up to nTbS of these values using equation 8-292. The final value can therefore be nTbS*CoeffMax. The reference code assumes that the values are at most 16bits unless compiled with a target of all_highbitdepth. This means that we can make a legal Main 4:4:4 10 stream that decodes differently depending on whether the reference code is compiled in highbitdepth mode or not. It seems to makes little sense for the residual values to be allowed to be this large as they will just be clipped during the reconstruction process." peterderivaz HM-16.2 1347 Chroma-QP-adjustment encoder granularity HM HM-16.2 defect closed 2014-11-07T16:50:53+01:00 2014-11-14T16:19:15+01:00 "The parameters for chroma-QP-adjustment (not to be confused with chroma-QP-offsets) are not searched for, but instead a checkerboard pattern is used when this feature is enabled. The granularity of this checkerboard pattern is down to the size of a CU. However, chroma-qp-adjustment can be restricted to be signalled at a higher depth. Currently, the encoder ignores this limit when calculating the 'm_ChromaQpAdjIdc', leading to an encoder-decoder mismatch. eg ./bin/TAppEncoderStatic -c cfg/encoder_intra_main_rext.cfg -c BasketballPass.cfg --SEIDecodedPictureHash=1 -f 1 --MaxCUChromaQpAdjustmentDepth=1 will produce a stream that the decoder will mismatch. A possible fix is to adjust the checkerboard to match the granularity of the signalling. In TEncCu::xCompressCU, Int lgMinCuSize = pcSlice->getSPS()->getLog2MinCodingBlockSize(); Change to Int lgMinCuSize = pcSlice->getSPS()->getLog2MinCodingBlockSize() + std::max(0, pcSlice->getSPS()->getLog2DiffMaxMinCodingBlockSize() - pcSlice->getPPS()->getMaxCuChromaQpAdjDepth()); " karlsharman HM-16.2 1350 mismatch between parameter list of TComTrQuant::init() and its invocation in TDecTop.cpp HM HM-16.2 defect closed 2014-11-14T00:09:58+01:00 2014-11-14T16:22:29+01:00 "There is a mismatch between declaration and use of TComTrQuant::init(). In TComTrQuant.cpp Void TComTrQuant::init( UInt uiMaxTrSize, Bool bUseRDOQ, Bool bUseRDOQTS, Bool bEnc, Bool useTransformSkipFast #if ADAPTIVE_QP_SELECTION , Bool bUseAdaptQpSelect #endif ) In TDecTop.cpp m_cTrQuant.init ( g_uiMaxCUWidth, g_uiMaxCUHeight, m_apcSlicePilot->getSPS()->getMaxTrSize()); This bug exists in HM-16.2 and also HM-dev. " dthoang HM-16.2 1351 error in parsing terminating bit that ends slice_segment_data HM HM-16.2 defect closed 2014-11-15T04:09:31+01:00 2014-11-17T15:07:11+01:00 "A recent change in TDecSlice.cpp introduced an error in the parsing of the terminating bit at the end of slice_segment_data. {{{ // Should the sub-stream/stream be terminated after this CTU? // (end of slice-segment, end of tile, end of wavefront-CTU-row) if (isLastCtuOfSliceSegment || ( ctuXPosInCtus + 1 == tileXPosInCtus + currentTile.getTileWidthInCtus() && ( ctuYPosInCtus + 1 == tileYPosInCtus + currentTile.getTileHeightInCtus() || wavefrontsEnabled) ) ) }}} Should be changed to: {{{ // Should the sub-stream/stream be terminated after this CTU? // (end of slice-segment, end of tile, end of wavefront-CTU-row) if (!isLastCtuOfSliceSegment && ( ctuXPosInCtus + 1 == tileXPosInCtus + currentTile.getTileWidthInCtus() && ( ctuYPosInCtus + 1 == tileYPosInCtus + currentTile.getTileHeightInCtus() || wavefrontsEnabled) ) ) }}} Please refer to syntax table 7.3.8.1 of the specification. " dthoang HM-16.2 1353 HM vs WD mismatch HM HM-16.2 defect closed 2014-12-05T18:22:06+01:00 2015-01-29T16:05:17+01:00 "line 1347 of TDecCAVLC.cpp contains something that seems not to be in specification: if ( pps->getChromaQpAdjTableSize() > 0 ) { READ_FLAG( uiCode, ""slice_chroma_qp_adjustment_enabled_flag"" ); pcSlice->setUseChromaQpAdj( uiCode != 0 ); } else { pcSlice->setUseChromaQpAdj( false ); }" kolya HM-16.2 1355 CAVLC encoder decoder mismatch HM HM-16.2 defect closed 2014-12-05T21:12:42+01:00 2014-12-08T17:54:51+01:00 "Read, never written: for(Int i=0; igetChromaQpAdjTableSize(); chromaQpAdjustmentIndex++) { WRITE_SVLC(pcPPS->getChromaQpAdjTableAt(chromaQpAdjustmentIndex).u.comp.CbOffset, ""cb_qp_adjustnemt[i]""); WRITE_SVLC(pcPPS->getChromaQpAdjTableAt(chromaQpAdjustmentIndex).u.comp.CrOffset, ""cr_qp_adjustnemt[i]""); } " kolya HM-16.2 1358 pps_extension_flag misleading syntax HM HM-16.2 defect closed 2014-12-12T19:35:57+01:00 2015-01-29T16:10:00+01:00 "In JCTVC-Q1003 document there is pps_extension_flag if( pps_extension_flag ) while( more_rbsp_data( ) ) pps_extension_data_flag rbsp_trailing_bits( ) while in JCTVC-Q1005 there is pps_extension_present_flag if( pps_extension_present_flag ) { pps_range_extensions_flag pps_extension_7bits } while in HM-dev s\w there is READ_FLAG( uiCode, ""pps_extension_present_flag""); if (uiCode) { Bool pps_extension_flags[NUM_PPS_EXTENSION_FLAGS]; for(Int i=0; i Target Field : .NAL units in Access Unit Section No : 9.19.1.1.4 Error Message : A position of VPS NAL unit is incorrect in the first AU order. Explanation : First access unit (AU) in a GOP shall have following NAL units in listed order. - An Access unit delimiter NAL unit - A VPS NAL unit - A SPS NAL unit - PPS NAL unit(s) - Prefix SEI NAL unit(s) - if exist - Slice segment(s) NAL units of an IDR or a CRA picture - Suffix SEI NAL unit(s) - if exist - A Filler data NAL unit - if exist(Note1) - An End of sequence NAL unit - if exist - An End of bitstream NAL unit - if exist Error ID : HEVC0030 Target File : 00000.m2ts Target Field : .overscan_appropriate_flag Section No : 9.19.1 Error Message : overscan_appropriate_flag in SPS is set to 1. It should be set to 0. Explanation : The following fields in SPS shall have the following pre-determined values. - overscan_appropriate_flag should be set to g0h if over_scan_info_present_flag is set to 1" brondijk HM-16.2 1341 some variables with Flag suffix declared as other than Bool HM HM-16.2 defect closed 2014-10-25T06:14:39+02:00 2014-10-29T16:26:13+01:00 "There are a few member variables that are named *Flag but not declared as Bool. For consistency these should be changed to type Bool and associated code should also be changed. For example, some code might use 1-fooFlag. " dthoang HM-16.2 1360 no syntax reading in code HM HM-16.2 defect closed 2014-12-17T00:35:58+01:00 2015-02-02T17:43:10+01:00 "There is no reading of colour_plane_id in HM-dev reference s\w, which is in the spec: slice_type ue(v) if( output_flag_present_flag ) pic_output_flag u(1) if( separate_colour_plane_flag = = 1 ) colour_plane_id u(2) " kolya HM-16.2 1342 TDecSbac::parseMVPIdx() could be simplified HM HM-16.2 enhancement new 2014-10-25T06:54:43+02:00 2014-10-25T06:54:43+02:00 "TDecSbac::parseMVPIdx() reads the syntax elements mvp_l0_flag and mvp_l1_flag, which can only take on values of 0 or 1. The routine uses xReadUnaryMaxSymbol() when it could simply use decodeBin()." dthoang HM-16.2 1365 Rename variables and functions for consistency with text. HM HM-16.2 enhancement assigned 2015-01-29T16:06:44+01:00 2015-03-25T14:53:28+01:00 "There are many inconsistencies between the text and the names of variable and accessor functions. Unification would require significant work although no functional differences. " karlsharman HM-16.14 1490 [SEI] no parameter set before recovery point SEI associated with non-IRAP frame. HM HM-16.14 defect new 2018-05-04T18:40:25+02:00 2018-05-04T18:40:25+02:00 "In general, the issue is that no parameter sets (VPS, PPS, SPS) appear before recovery point SEI associated with non-IRAP (e.g. IDR, CRA) frame if DecodingRefreshType is set as 3 (Recovery Point SEI). The version is actually latest 16.18, I ran with a sample cfg file encoder_randomaccess_main10.cfg (only change DecodingRefreshType to 3) with a sample video BasketballDrill_832x480_50_qp37.yuv, the output video has the issue above. The reason it is an issue is that since it is a recovery point SEI, it should provide all the parameter sets so that the decoder can start decoding from this point which does not need to know anything before. This issue doesn't happen if the DecodingRefreshType is 1 (CRA) or 2 (IDR). The command line is ./bin/TAppEncoderStatic -c ./cfg/encoder_randomaccess_main10.cfg -i BasketballDrill_832x480_50_qp37.yuv --FrameRate=25 --InputBitDepth=8 --InputChromaFormat=420 --SourceHeight=480 --SourceWidth=832 -f 200 --SEIRecoveryPoint -b str.265 The cfg file and video is in the attachment. Thanks a lot!" barry963 HM-16.14 1465 Wrong payload type for alternative_transfer_characteristics SEI message HM HM-16.14 defect closed 2017-02-10T01:04:02+01:00 2017-02-16T16:26:37+01:00 "The current payloadType for this SEI message is still equal to the old ICD (182) in SEI.h; ALTERNATIVE_TRANSFER_CHARACTERISTICS = 182, This should be now amended to 147 as indicated in V3 of the spec." matteon HM-16.14 1503 Werror in the linux version of HM-16.14+SCM-8.3 HM HM-16.14 defect new 2018-12-05T21:08:11+01:00 2020-09-23T09:36:11+02:00 "I am trying to build HM-16.14+SCM-8.3 in linux, however I am having the following issue: /media/ozcinar/5794A6616D9A2329/Backup/ozchinar/software/HM-16.14+SCM-8.3/build/linux/lib/TLibDecoder/../../../../source/Lib/TLibDecoder/TDecTop.cpp:336:38: error: variable ‘tempIterPic’ set but not used [-Werror=unused-but-set-variable] " ozcinarc HM-16.14 1463 Illegal instructions on MS Visual Studio 2015 Update 3 HM HM-16.14 defect new 2017-01-30T14:23:29+01:00 2017-02-01T20:58:14+01:00 "When encoding/decoding with a release build on MS Visual Studio 2015 Update 3, an ""Illegal Instruction Error"" is produced in ""partialButterflyInverse32"". This looks like a problem with the optimizer of Visual Studio's C++ compiler. The debug version works fine. The bug could be reported to MS, but it should probably be reduced to a very simple example code that could easily be analyzed by the developers (if possible). The current suggested solution is to use a different compiler as a workaround and wait for the next VS update. There seems to be at least one existing bug report for VS referring to ""illegal instructions""" ksuehring HM-16.14 1466 SEIs for skipped pictures assigned to non-skipped picture HM HM-16.14 defect new 2017-02-27T16:13:54+01:00 2017-02-27T16:13:54+01:00 "When decoding streams with RASLs, SEIs associated with the skipped RASL pictures are associated with the previous non-skipped picture. e.g. in conformance streams RAP_B_Bossen_2 and NoOutPrior_A_Qualcomm_1, HM interprets POC-32 as having 8 associated SEI hash messages. However, this is because 7 pictures have been skipped. HM currently produces a warning and just uses the first SEI hash message; it would be better to drop the SEI messages." karlsharman HM-16.14 1468 Console output error of nQP when LCU level rate control is on HM HM-16.14 defect new 2017-03-10T10:39:59+01:00 2017-03-10T10:39:59+01:00 "When encoding, nQP and QP is outputed in the console. nQP means the nearest QP to the step size in JCTVC-G382, and have different value with QP only when the option AdaptiveQpSelection(-aqps) is enabled. However, when LCU level rate control is on, nQP is different from QP for every frame, including I frames. For current HM software, when LCU level rate control is enabled, the output value of nQP is the QP of last LCU in current frame. The QP of last LCU in current frame should not be assigned to TComSlice::m_iSliceQpBase. The following code in the function body of TEncSlice::compressSlice should be removed: #if ADAPTIVE_QP_SELECTION pCtu->getSlice()->setSliceQpBase( estQP ); #endif After removing these code, all of output information in console remain the same except nQP value in RA and LD cases. " FangliangSong HM-16.14 1471 Mismatch between the description of FramesToBeEncoded default parameter and encoder behaviour HM HM-16.14 defect new 2017-04-19T18:12:47+02:00 2017-04-20T17:25:10+02:00 "In the JCTVC-Software Manual (applying to version 16.15 of the software), is written that the default value for the FramesToBeEncoded parameter is 0 and that ""When 0, all frames are coded"", but if the executable of TAppEncoder is used without providing a value for FramesToBeEncoded, the following error message is notified: ""Error: Total Number Of Frames encoded must be more than 0"" NOTE: Tested on HM software: Encoder Version [16.15] (including RExt)[Mac OS X][GCC 4.2.1][64 bit] " fra2017 HM-16.14 1475 Difference between HM and spec. on green metadata SEI HM HM-16.14 defect new 2017-05-25T03:48:59+02:00 2017-05-26T13:21:08+02:00 "In the specification, green metadata SEI is not allowed in the SUFFIX_SEI_NUT. But in the HM16.15, green metadata SEI write and read in the SUFFIX_SEI_NUT." Haruhiko HM-16.14 1476 wrong index HM HM-16.14 defect new 2017-05-25T11:41:28+02:00 2017-05-25T11:41:28+02:00 "iPartIdx, instead of uiAbsPartIdx, is used in pcCU->getCUTransquantBypass(iPartIdx) in TEncSearch::xGetInterPredictionError(). m_pcRdCost->setDistParam( cDistParam, pcCU->getSlice()->getSPS()->getBitDepth(CHANNEL_TYPE_LUMA), pcYuvOrg->getAddr( COMPONENT_Y, uiAbsPartIdx ), pcYuvOrg->getStride(COMPONENT_Y), m_tmpYuvPred .getAddr( COMPONENT_Y, uiAbsPartIdx ), m_tmpYuvPred.getStride(COMPONENT_Y), iWidth, iHeight, m_pcEncCfg->getUseHADME() && (pcCU->getCUTransquantBypass(iPartIdx) == 0) );" libin HM-16.14 1492 Trouble compiling with Visual Studio 2015 HM HM-16.14 defect new 2018-07-09T20:13:45+02:00 2018-07-09T20:13:45+02:00 "'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Cannot find or open the PDB file. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Cannot find or open the PDB file. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Cannot find or open the PDB file. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'. Symbols loaded. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'. Cannot find or open the PDB file. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'. Cannot find or open the PDB file. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. Symbols loaded. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'. Symbols loaded. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\sspicli.dll'. Symbols loaded. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\bcryptprimitives.dll'. Cannot find or open the PDB file. 'TAppEncoder.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'. Cannot find or open the PDB file. The program '[1588] TAppEncoder.exe' has exited with code 1 (0x1)." ebongfrank HM-16.14 1497 bugs on handling tile parameters in parseCfg() HM HM-16.14 defect closed 2018-09-06T07:53:07+02:00 2018-09-06T18:50:44+02:00 "==Summery== We found out that the Encoder config file parser could not correctly handling the size of tile columns or rows array configuration. Revision 4974 =='''Bugs Location 1'''== source\App\TAppEncoder\TAppEncCfg.cpp:1279~1330 *Problem: While try to catch unexpected tile columns/rows array configuration, there should be using ''m_numTileColumns/RowsMinus1 +1 ''instead of ''m_numTileColumns/RowsMinus1''. ===Original Source-code=== {{{ #!cpp if( !m_tileUniformSpacingFlag && m_numTileColumnsMinus1 > 0 ) { > if (cfg_ColumnWidth.values.size() > m_numTileColumnsMinus1) { printf( ""The number of columns whose width are defined is larger than the allowed number of columns.\n"" ); exit( EXIT_FAILURE ); } > else if (cfg_ColumnWidth.values.size() < m_numTileColumnsMinus1) { printf( ""The width of some columns is not defined.\n"" ); exit( EXIT_FAILURE ); } else { > m_tileColumnWidth.resize(m_numTileColumnsMinus1); for(UInt i=0; i 0 ) { > if (cfg_ColumnWidth.values.size() > (m_numTileColumnsMinus1+1)) { printf( ""The number of columns whose width are defined is larger than the allowed number of columns.\n"" ); exit( EXIT_FAILURE ); } > else if (cfg_ColumnWidth.values.size() < (m_numTileColumnsMinus1+1)) { printf( ""The width of some columns is not defined.\n"" ); exit( EXIT_FAILURE ); } else { > m_tileColumnWidth.resize(m_numTileColumnsMinus1+1); for(UInt i=0; i for(Int i=0; i if( uiCummulativeColumnWidth >= iWidthInCU ) { printf( ""The width of the column is too large.\n"" ); exit( EXIT_FAILURE ); } }}} ===Possible solution=== {{{ #!cpp > for(Int i=0; i<(m_iNumColumnsMinus1+1); i++) { uiCummulativeColumnWidth += m_tileColumnWidth[i]; } > if( uiCummulativeColumnWidth > iWidthInCU ) { printf( ""The width of the column is too large.\n"" ); exit( EXIT_FAILURE ); } }}}" vulcano HM-16.14 1501 HM 16.20 fails to build with gcc8 HM HM-16.14 defect new 2018-11-17T17:42:11+01:00 2019-08-06T04:00:33+02:00 "HM 16.20 fails to build with gcc8, giving the following error: {{{ In file included from /storage/linux/src/hm/build/linux/lib/TLibCommon/../../../../source/Lib/TLibCommon/ContextModel3DBuffer.cpp:38: /storage/linux/src/hm/build/linux/lib/TLibCommon/../../../../source/Lib/TLibCommon/ContextModel3DBuffer.h: In member function ‘Void ContextModel3DBuffer::copyFrom(const ContextModel3DBuffer*)’: /storage/linux/src/hm/build/linux/lib/TLibCommon/../../../../source/Lib/TLibCommon/ContextModel3DBuffer.h:91:85: error: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of non-trivially copyable type ‘class ContextModel’; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] ::memcpy( m_contextModel, src->m_contextModel, sizeof(ContextModel) * m_sizeXYZ ); ^ In file included from /storage/linux/src/hm/build/linux/lib/TLibCommon/../../../../source/Lib/TLibCommon/ContextModel3DBuffer.h:45, from /storage/linux/src/hm/build/linux/lib/TLibCommon/../../../../source/Lib/TLibCommon/ContextModel3DBuffer.cpp:38: /storage/linux/src/hm/build/linux/lib/TLibCommon/../../../../source/Lib/TLibCommon/ContextModel.h:57:7: note: ‘class ContextModel’ declared here class ContextModel ^~~~~~~~~~~~ cc1plus: all warnings being treated as errors make[1]: *** [../../common/makefile.base:241: objects/ContextModel3DBuffer.r.o] Error 1 make[1]: Leaving directory '/storage/linux/src/hm/build/linux/lib/TLibCommon' make: *** [makefile:49: release] Error 2 }}} * It builds fine with gcc 7.3.1. * It builds with gcc8 when removing `-Werror` from `build/linux/common/makefile.base`. Steps used to build: {{{ $ svn checkout -r 4994 https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk/ hm $ cd hm/build/linux $ make -j1 -f makefile release release_highbitdepth }}} '''System Information:''' '''OS:''' Arch Linux x86_64 '''Compiler:''' gcc 8.2.1 '''HM:''' 16.20 (svn revision 4994)" dbermond HM-16.14 1502 Using independent substreams for compressSlice I get x3 more bits per POC HM HM-16.14 defect new 2018-11-25T19:17:04+01:00 2018-11-25T19:17:04+01:00 "Using independent substreams for compressSlice(..), I get about x3 times more bits for every POC ie 286816 bits with original code and about 940000 bits with the independent substreams method. It supposed that HM will take care of this job. So its a bug or not implemented feature ? I am attaching you two images a) the original encoding and b) the modified encoding " sdancer75 HM-16.14 1509 mismatches in PCM alignment syntax HM HM-16.14 defect closed 2020-08-27T11:17:45+02:00 2020-10-09T08:51:19+02:00 "In the spec, we have the syntax below. while (!byte_aligend()) pcm_alignment_zero_bit However, it need to write ""1"" before align zero in HM. Void TEncBinCABAC::encodePCMAlignBits() { finish(); m_pcTComBitIf->write(1, 1); m_pcTComBitIf->writeAlignZero(); // pcm align zero } Could anyone help to check if it is a mismatch? Thx " wangli HM-16.14 1510 Typo in command-line option HM HM-16.14 defect new 2020-10-07T08:53:02+02:00 2020-10-07T08:53:02+02:00 "Typo ""SEIPreferredTransferCharacterisics"" reported in VTM bug tracker was also found in HM. This should be ""SEIPreferredTransferCharacteristics"". MR!38 was submitted." siwamura HM-16.14 1514 Problems with HM Software Manual HM HM-16.14 defect new 2021-10-14T04:17:39+02:00 2021-10-14T04:17:39+02:00 "I am reading the HM Software Manual. And I find there may be a wrong description in this manual. In the current version HM Software Manual (https://vcgit.hhi.fraunhofer.de/jvet/HM/-/blob/master/doc/software-manual.pdf, Date Saved 2021-10-05), 6th page, the last paragraph starting with ""In Frame2, reference ..."", the sentence ""In the Frame2, reference pictures with POC 0 and 2 are used,"" should be changed into ""In the Frame2, reference pictures with POC 0 and 4 are used."" Based on my current knowledge, the current description is wrong. Hope you can correct it or tell me why the description should not be changed. Thank you!" cupcup HM-16.14 1517 HM outputs 40 frames for the test-vector NoOutPrior_A_Qualcomm_1.hevc HM HM-16.14 defect new 2022-08-12T23:05:45+02:00 2022-08-12T23:09:58+02:00 "For the test-vector NoOutPrior_A_Qualcomm_1.hevc the HM decoder outputs 40 frames, but in the [https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/tast-tests/src/chromiumos/tast/local/bundles/cros/video/data/test_vectors/hevc/main/NoOutPrior_A_Qualcomm_1_readme.txt README] for this test-vector, it states there should be 50 frames. Should it be expected that all 50 frames are outputted? The reason I am bringing this up, is that when the video only contains 40 frames it appears as if frames are missing. This becomes especially evident when compared to the outputted stream where all 50 frames are outputted. I added two mp4s (one with 40 frames and one with 50 frames) which show the difference between the two videos. Since the README states 50 frames and the video that includes 50 frames has better quality, I am curious if 40 frames is actually the correct amount of frames that should be outputted. " allenjoey89 HM-16.14 1519 Fails to create correct cmake project HM HM-16.14 defect new 2023-02-03T14:07:07+01:00 2023-02-03T14:07:07+01:00 Using cmake-gui if one selects ENABLE_360_VIDEO then fails to create correct configuration since there is no Lib360, AppEncHelper360 and 360ConvertApp hamlatzis HM-16.13 1462 Cygwin Install HM HM-16.13 defect closed 2017-01-16T18:00:13+01:00 2017-01-18T16:27:23+01:00 Can anyone explain how to run the makefile inside the build/linux on cygwin, without errors? mbernardo HM-16.13 1460 MV search range in HM-16.13 HM HM-16.13 defect closed 2016-11-17T05:00:39+01:00 2016-11-22T18:38:30+01:00 "At the Chengdu meeting, it was agreed to use 256 MV search range for RA, but it seems the latest HM(HM16.13)'s cfg(encoder_randomaccess_main.cfg and encoder_randomaccess_main10.cfg) remains to use 64. SearchRange : 64 # (0: Search range is a Full frame) In the meeting note (JCTVC-Y_Notes_d3.doc): JCTVC-Y0052 BoG ... The increased motion search range was especially suggested for high resolutions like class A and random access. Further discussed Thu 1620 (GJS): Decision (CTC SW): Use 256 for RA only (all picture resolutions). " Tomohiro Ikai HM-16.13 1464 local RPS usage in arrangeLongtermPicturesInRPS HM HM-16.13 defect new 2017-02-06T09:42:12+01:00 2017-02-06T09:42:12+01:00 "With the change of #4483 (corresponding to HM-16.6), local RPS(pcSlice->getLocalRPS()) became used instead of pcSlice->getRPS() in arrangeLongtermPicturesInRPS(). #The change also involves const for pcSlice->getRPS(). But the original implementation (seems from HM-7.1 for I0342, #define CODE_POCLSBLT_FIXEDLEN) would only work with pcSlice->getRPS(), because in many cases local RPS would be empty (not initialalized/set). Exception cases (local RPS can be valid) would be that createExplicitReferencePictureSetFromReference is called beforehand in TEncGOP.cpp due to a loss detection (return non-zero in checkThatAllRefPicsAreAvailable or IRAP. The createExplicit... prepares local RPS. The patch (relative to HM-16.13) may resolve this issue. two possible options: FIX_LOCAL_RPS==1: revert local RPS usage, which needs const removal (not included in the patch for the removal part) FIX_LOCAL_RPS==2: copy pcSlice->getRPS() data to local RPS (if needed) and use local RPS. Note: the issue is not related to CTC. The fix may not be good enough..(i not so familiar with this area) " Tomohiro Ikai HM-16.12 1457 HM x64 Release build and Debug build generate different results HM HM-16.12 defect closed 2016-10-19T08:46:44+02:00 2016-11-22T18:41:19+01:00 "I used VS2013 to compile the latest HM (HM-dev r4815) into x64 Debug version and Release version. The command line I used was TAppEncoder -c encoder_lowdelay_main.cfg -c BQSquare.cfg -f 1 The coding result of Release build is POC 0 TId: 0 ( I-SLICE, nQP 32 QP 32 ) 91576 bits [Y 33.5217 dB U 39.4202 dB V 40.0321 dB] [ET 1 ] [L0 ] [L1 ] The coding result of Debug build is POC 0 TId: 0 ( I-SLICE, nQP 32 QP 32 ) 89352 bits [Y 33.3534 dB U 39.4079 dB V 39.8650 dB] [ET 8 ] [L0 ] [L1 ] I've checked other versions of HM. r4793 seems to be OK (Debug and Release version generate identical results, which is the same as the Release result above). But r4794 has the same problem. I've also checked that disabling SHARP_LUMA_DELTA_QP in r4815 can also solve the problem." libin HM-16.12 1453 Rate control support for 16-picture GOP HM HM-16.12 enhancement new 2016-07-06T07:07:42+02:00 2016-07-06T07:07:42+02:00 "Currently HM rate control only supports a 4-picture LD GOP or an 8-picture RA GOP when KeepHierarchicalBit is set to anything other than equal bit allocation. Support should be added for a 16-picture RA GOP (note that such a structure is used in the JEM, so adding to HM may facilitate performance comparisons). The functions of interest are TEncRCGOP::create() and TEncRateCtrl::init()." crosewarne HM-16.1 1330 Repeated reference picture sets cause dangling pointers HM HM-16.1 defect closed 2014-10-14T14:05:24+02:00 2014-11-11T12:02:19+01:00 "This is a repeat of #1099, but as that ticket is so old I thought it would be best to repost with updated patches. It is legal to repeat the active SPS and VPS during a CVS, provided that its content doesn't change. However, the reference code stores pointers to SPS and VPS objects on each picture, and deletes the active set if such repeating occurs, leaving dangling pointers on the pictures. Our patch stores all the pointers in a list and deletes them when the reference decoder shuts down, ensuring that any previous stored pointers remain valid. Patches are attached for HM-16.1 and HM-15.0+RExt-8.1. " jackh HM-16.1 1332 Double read of SEI byte alignment when payload extension present HM HM-16.1 defect closed 2014-10-14T15:39:52+02:00 2014-10-17T20:25:09+02:00 "The reference code currently doesn't handle payload extensions in SEI messages correctly. In SEIread.cpp, each SEI parsing function calls xParseByteAlign() before returning. The payload extension decoding code (in SEIReader::xReadSEImessage(), line 328) then reads the payload extension followed by another alignment. According to the spec, the payload extension should be read before any alignnment. The reference code only fails when there is a payload extension present, as the code at the end of xReadSEImessage() only runs if there are bits remaining in the buffer. The solution is to remove the calls to xParseByteAlign()." jackh HM-16.1 1333 Leading pictures are sometimes skipped or not skipped incorrectly HM HM-16.1 defect new 2014-10-15T12:43:58+02:00 2016-02-20T03:54:50+01:00 "The rules governing the skipping of leading pictures as I understand them are: * RASLs should be skipped (not output) in the first IRAP of a new CVS. * RADLs are never skipped. * RASLs following a subsequent IRAP inside a CVS should not be skipped. The reference decoder handles this by means of the function TDecTop::isRandomAccessSkipPicture(), which returns true to skip the picture. It determines whether pictures should be skipped by means of the variable m_pocRandomAccess, which takes the following values: * m_pocRandomAccess==MAX_INT: waiting to be set * m_pocRandomAccess==-MAX_INT: inside an IDR IRAP, no RASLs should be skipped. * Other values: contains POC of IRAP picture. RASLs should be skipped. The current implementation doesn't handle the case where a subsequent CRA IRAP is encoded within a CVS. So if you had a BLA IRAP followed by a CRA IRAP with no EOS NAL unit between them, the following would happen: 1. Start. m_pocRandomAccess==MAX_INT. 2. Decode BLA. m_pocRandomAccess=. 3. Decode leading and trailing pictures. RASLs are skipped if their POCs are less than the POC of the BLA picture. 3. Decode CRA. m_pocRandomAccess is not changed as m_pocRandomAccess!=MAX_INT. RASLs are arbitrarily skipped if their POCS are less than the POC of the BLA picture. As m_pocRandomAccess is only ever changed if m_pocRandomAccess==MAX_INT, and is only ever reset to MAX_INT when an EOS is encountered, it is possible to end up checking the POCs of RASLs against pictures that occurred many CVSs ago. The attached patch addresses this issue by setting m_pocRandomAccess correctly for mid-CVS CRA pictures. " jackh HM-16.1 1334 Reference decoder sometimes skips RADLs HM HM-16.1 defect new 2014-10-15T12:52:36+02:00 2016-02-20T03:54:50+01:00 "This ticket is related to #1333. TDecTop::xDecodeSlice() contains the following section of code: {{{ // exit when a new picture is found if (!m_apcSlicePilot->getDependentSliceSegmentFlag() && (m_apcSlicePilot->getSliceCurStartCtuTsAddr() == 0 && !m_bFirstSliceInPicture) ) { if (m_prevPOC >= m_pocRandomAccess) { m_prevPOC = m_apcSlicePilot->getPOC(); #if ENC_DEC_TRACE //rewind the trace counter since we didn't actually decode the slice g_nSymbolCounter = originalSymbolCount; #endif return true; } m_prevPOC = m_apcSlicePilot->getPOC(); } }}} The line {{{if (m_prevPOC >= m_pocRandomAccess)}}} doesn't discriminate between RASLs and RADLs, so can lead to RADLs being skipped in error. I don't think there's any need for this conditional, as RASLs will be skipped by the if statement just above which calls isRandomAccessSkipPicture(). I would therefore suggest that the above section of code be changed to: {{{ // exit when a new picture is found if (!m_apcSlicePilot->getDependentSliceSegmentFlag() && (m_apcSlicePilot->getSliceCurStartCtuTsAddr() == 0 && !m_bFirstSliceInPicture) ) { m_prevPOC = m_apcSlicePilot->getPOC(); #if ENC_DEC_TRACE //rewind the trace counter since we didn't actually decode the slice g_nSymbolCounter = originalSymbolCount; #endif return true; m_prevPOC = m_apcSlicePilot->getPOC(); } }}}" jackh HM-16.1 1335 NoOutputOfPriorPicsFlag can be mishandled by reference decoder HM HM-16.1 defect new 2014-10-15T14:01:46+02:00 2016-02-20T03:54:50+01:00 "TDecTop::checkNoOutputPriorPics(), called following an IRAP picture for which NoOutputOfPriorPicsFlag==1 (call this picture A), unsets the output flag on all pictures except pictures whose POC is the same as picture A (this value is held in m_lastPOCNoOutputPriorPics). This can cause pictures to be output in error if a picture held in the DPB from the previous IRAP has the same POC as picture A. In this case the picture will not have its output flag unset and may be output later. There is no need for this POC check as picture A will not yet have been added to the DPB when checkNoOutputPriorPics() is called, so there is no danger of incorrectly setting its output flag. I therefore suggest that this condition be removed from checkNoOutputPriorPics(). Since the variable m_lastPOCNoOutputPriorPics no longer has any purpose once this check is removed, the variable can also be removed." jackh HM-16.1 1336 Incorrect NoOutputOfPriorPicsFlag flushing behaviour after EOS HM HM-16.1 defect new 2014-10-15T15:39:26+02:00 2016-02-20T03:54:50+01:00 "This ticket is related to #1335. In TAppDecTop::decode() there is the following section of code: {{{ // write reconstruction to file if( bNewPicture ) { xWriteOutput( pcListPic, nalu.m_temporalId ); } if ( (bNewPicture || nalu.m_nalUnitType == NAL_UNIT_CODED_SLICE_CRA) && m_cTDecTop.getNoOutputPriorPicsFlag() ) { m_cTDecTop.checkNoOutputPriorPics( pcListPic ); m_cTDecTop.setNoOutputPriorPicsFlag (false); } }}} There are two bugs here which happen when an EOS is followed by a new CVS beginning with a CRA NAL unit. When the EOS is encountered, xWriteOutput() gets called by this piece of code from further down the function: {{{ if (nalu.m_nalUnitType == NAL_UNIT_EOS) { xWriteOutput( pcListPic, nalu.m_temporalId ); m_cTDecTop.setFirstSliceInPicture (false); } }}} xWriteOutput thus gets called twice before the flush in this case, where it would otherwise be called once, causing incorrect extra output. The call to xWriteOutput when an EOS NUT is encountered should therefore be removed. The other bug is that asserts validating the state of the RPS (in TComSlice::checkLeadingPictureRestrictions()) can fire on the prior pictures whilst they are still in the buffer after the call to checkNoOutputPriorPics(). To fix this, a call to xFlushOutput() should be added after the call to checkNoOutputPriorPics(). A patch for these changes is attached." jackh HM-16.1 1338 Adaptive QP Selection and multiple slices / slice segments HM HM-16.1 defect new 2014-10-17T15:27:18+02:00 2014-10-17T15:27:18+02:00 "Adaptive QP selection appears to be incorrect when multiple slices / slice segments are used. The statistics are reset at the start of compressSlice, and the delta calculated previously is added to the QpBase (a rate-controlled version of the slice's QP, used only for Adaptive Qp Selection) if the slice is not an I_SLICE. The statistics are used to update the delta at the end of encodeSlice. However, all slices are compressed. Once all slices are compressed, they are then encoded. So the statistics will only ever represent values gathered from the last slice of the previously coded picture. Is the intension to gather statistics on a picture and use that for the next picture, or to gather statistics on a slice (including all slice segments) and use that for the next slice? In addition, the 52 element array TComTrQuant::m_qpDelta will underflow if negative QPs are used as an index (valid for bit depths > 8)." karlsharman HM-16.1 1339 calCostSliceI, rate control and multiple slices/slice segments HM HM-16.1 defect new 2014-10-17T15:33:37+02:00 2014-10-17T15:33:37+02:00 "calCostSliceI is only called once per picture, even if there are multiple slices/slice segments. Is this the intended operation? Has the combination of multiple slices/slice segments with rate control been examined?" karlsharman HM-16.1 1340 Wrong conformance/default display window dimensions for field decoding HM HM-16.1 defect closed 2014-10-17T18:43:26+02:00 2014-10-17T18:44:57+02:00 "In HM 15 left and top output window position is ignored (while the size is calculated properly) RExt contained a rewrite of these functions, but makes the mistake to scale the vertical cropping components." ksuehring HM-16.0 1322 Slice mode broken in HM16.0 HM HM-16.0 defect closed 2014-09-11T00:24:06+02:00 2014-10-10T16:32:09+02:00 "The slice mode in HM16.0 is broken. For example, if SliceMode is set to 1 and SliceArgument is set to 30 for a 1080p sequence, the encoder creates bitstream which leads to decoder crash. The problem did not exist in HM15.0, but in HM-15.0+RExt-8.1" zhou HM-16.0 1324 Scalable nesting SEI syntax at encoder HM HM-16.0 defect closed 2014-09-25T02:38:19+02:00 2014-10-10T16:32:09+02:00 The syntax structure of the scalable nesting SEI message has one duplicated syntax element at the encoder . The attached patch removes that, and corrects the names of some syntax elements. adarsh HM-16.0 1325 Tiles result in incorrect entry-point values in dependent slice segments HM HM-16.0 defect closed 2014-10-03T16:49:01+02:00 2014-10-10T16:32:09+02:00 "When tiles (not wavefronts) are used, the first entry point value of each dependent slice-segment is incorrect. The entry point value includes the length of data in the previous slice-segments. The decoder does not currently use/check the entry point values for tile-only streams. Quick-fix: ensure that uiOneBitstreamPerSliceLength is always 0 in TEncGOP::compressGOP (or remove the TileOffstForMultES mechanism)." karlsharman HM-16.0 1327 Encoder: Incorrect decoding unit info in picture timing SEI HM HM-16.0 defect ksuehring closed 2014-10-09T12:31:51+02:00 2015-02-19T17:57:35+01:00 "When decoding unit information is encoded in picture timing SEI, the calculations for the syntax elements num_nalus_in_du_minus1 and du_cpb_removal_delay_increment_minus1[ i ] ignore SEI messages. The standard text has no exception for NAL units containing SEI messages, so these should be counted (which is complicated because it might not be known in advance, how many NAL units are written)" ksuehring HM-16.0 1328 Encoder: Decoding unit info encoding may fail and is only available for SliceMode=1 HM HM-16.0 defect ksuehring closed 2014-10-09T12:38:38+02:00 2015-02-19T17:59:14+01:00 "Decoding units information is only generated for SliceMode=1. Other Slice modes (and dependent slice segment modes) are also interesting use cases. The encoder may also crash in other slice modes (or slices disabled) when picture timing SEI is enabled and SliceArgument is too small due to a division by zero. Also, when using the SliceArgument parameter for calculating the number of DUs, it is still scaled by the CTU depth (which is probably the last remaining piece of fine granular slices)." ksuehring HM-16.0 1329 Encoder: nuh_temporal_id for SEI messages HM HM-16.0 defect ksuehring closed 2014-10-09T12:43:36+02:00 2015-02-19T17:58:36+01:00 nuh_temporal_id is always set to 1 for some SEI types, instead of the nuh_temporal_id of the associated picture. ksuehring HM-16.0 1345 AdaptiveQp activity calculation error HM HM-16.0 defect closed 2014-10-29T11:02:14+01:00 2015-08-13T11:33:48+02:00 "In TEncPreanalyzer::xPreanalyze(...) (TEncPreanalyzer.cpp) The sum of luma sample values and squared values is accumulated for each quadrant of a 2Nx2N cu - so each accumulates over NxN values, but the average is then calculated by dividing through by ""uiNumPixInAQPart"" which counts values over the whole 2Nx2N. i.e. - for a 16x16 Cu, the 4 sums are accumulated over 64 values each, but the average value is calculated by dividing by 256. This gives an incorrect value for the variance of the blocks. Possible fix - Delete "", uiNumPixInAQPart++"" in each of the 4 inner loops and insert at line 121 uiNumPixInAQPart = uiCurrAQPartWidth*uiCurrAQPartHeight/4; " rikallen HM-16.0 59 Memory issue - unnecessarily long variable type HM HM-16.0 enhancement closed 2010-08-19T13:54:36+02:00 2014-09-12T16:22:10+02:00 "Comments from Tourapis, Alexis. Thanks! Currently motion vector and reference indices use Int-type variable. There are other cases using unnecessarily long variable type. Check them and replace them by suitable types. It can reduce memory considerably. " wjhan HM-14.0 1301 Tile check should be done only when tiles are enabled HM HM-14.0 defect closed 2014-07-03T15:35:05+02:00 2014-07-04T09:22:53+02:00 "Revision r4006 introduced TILE_SIZE_CHECK block of code which works even when tiles are not enabled in the stream. This makes decoding small resolution streams impossible. Specification states that profile checks for tile column width and height should be done only ""When a PPS has tiles_enabled_flag equal to 1"". These checks should be done only when tiles are enabled." gregory HM-14.0 1303 Next CVS headers are activated before previous has filters executed because of APS SEI HM HM-14.0 defect closed 2014-07-10T15:28:59+02:00 2014-11-11T12:02:19+01:00 Attached stream has two CVS, each CVS has VPS/SPS/PPS ID set to zero which is allowed by spec both because headers are placed between CVS NAL units and because headers have identical information. But when decoder encounters second APS SEI it activates headers deleting old data structures from memory even though SAO filter is not executed for the last CVS frame. In this example PCM restoration fails because SPS->m_bPCMFilterDisableFlag, SPS->m_uiPCMBitDepthLuma and SPS->m_uiPCMBitDepthChroma values have garbage after SPS memory block is freed from memory. Other references to headers, e.g. in deblocking may get garbage too. gregory HM-14.0 1314 HM Rate Control Bug HM HM-14.0 defect new 2014-08-26T13:34:16+02:00 2014-10-10T15:59:05+02:00 " Based on: jctvc-hm-84d6b158ca1f92cd06840a798b4b11ba22d0586b.zip HM 16.0 Visual C++ 10: In the function ""Void TEncGOP::compressGOP()"", there are codes: if ( m_pcCfg->getUseRateCtrl() ) { Int frameLevel = m_pcRateCtrl->getRCSeq()->getGOPID2Level( iGOPid ); if ( pcPic->getSlice(0)->getSliceType() == I_SLICE ) { frameLevel = 0; } m_pcRateCtrl->initRCPic( frameLevel ); estimatedBits = m_pcRateCtrl->getRCPic()->getTargetBits(); Int sliceQP = m_pcCfg->getInitialQP(); if ( ( pcSlice->getPOC() == 0 && m_pcCfg->getInitialQP() > 0 ) || ( frameLevel == 0 && m_pcCfg->getForceIntraQP() ) ) // QP is specified { Int NumberBFrames = ( m_pcCfg->getGOPSize() - 1 ); Double dLambda_scale = 1.0 - Clip3( 0.0, 0.5, 0.05*(Double)NumberBFrames ); Double dQPFactor = 0.57*dLambda_scale; Int SHIFT_QP = 12; Int bitdepth_luma_qp_scale = 0; Double qp_temp = (Double) sliceQP + bitdepth_luma_qp_scale - SHIFT_QP; lambda = dQPFactor*pow( 2.0, qp_temp/3.0 ); } else if ( frameLevel == 0 ) // intra case, but use the model { '''m_pcSliceEncoder->calCostSliceI(pcPic);''' if ( m_pcCfg->getIntraPeriod() != 1 ) // do not refine allocated bits for all intra case { Int bits = m_pcRateCtrl->getRCSeq()->getLeftAverageBits(); bits = m_pcRateCtrl->getRCPic()->getRefineBitsForIntra( bits ); if ( bits < 200 ) { bits = 200; } m_pcRateCtrl->getRCPic()->setTargetBits( bits ); } list listPreviousPicture = m_pcRateCtrl->getPicList(); m_pcRateCtrl->getRCPic()->getLCUInitTargetBits(); lambda = m_pcRateCtrl->getRCPic()->estimatePicLambda( listPreviousPicture, pcSlice->getSliceType()); sliceQP = m_pcRateCtrl->getRCPic()->estimatePicQP( lambda, listPreviousPicture ); } else // normal case { list listPreviousPicture = m_pcRateCtrl->getPicList(); lambda = m_pcRateCtrl->getRCPic()->estimatePicLambda( listPreviousPicture, pcSlice->getSliceType()); sliceQP = m_pcRateCtrl->getRCPic()->estimatePicQP( lambda, listPreviousPicture ); } sliceQP = Clip3( -pcSlice->getSPS()->getQpBDOffset(CHANNEL_TYPE_LUMA), MAX_QP, sliceQP ); m_pcRateCtrl->getRCPic()->setPicEstQP( sliceQP ); m_pcSliceEncoder->resetQP( pcPic, sliceQP, lambda ); } The line ""m_pcSliceEncoder->calCostSliceI(pcPic);"" can calculate the total intra cost and make the member variable m_pcRateCtrl->m_encRCPic->m_totalCostIntra properly initialized. But when rate control is turned on and the input parameter ""initialQP"" is not set to 0 (e.g. set to 32), the line ""m_pcSliceEncoder->calCostSliceI(pcPic);"" is not executed for the first I Frame. At this time, for the first I frame, the member variable m_pcRateCtrl->m_encRCPic->m_totalCostIntra will not be properly initialized. After encoding the first I frame, the following codes in the function ""Void TEncGOP::compressGOP()"" will be executed: if ( m_pcCfg->getUseRateCtrl() ) { Double avgQP = m_pcRateCtrl->getRCPic()->calAverageQP(); Double avgLambda = m_pcRateCtrl->getRCPic()->calAverageLambda(); if ( avgLambda < 0.0 ) { avgLambda = lambda; } '''m_pcRateCtrl->getRCPic()->updateAfterPicture( actualHeadBits, actualTotalBits, avgQP, avgLambda, pcSlice->getSliceType()); ''' m_pcRateCtrl->getRCPic()->addToPictureLsit( m_pcRateCtrl->getPicList() ); m_pcRateCtrl->getRCSeq()->updateAfterPic( actualTotalBits ); if ( pcSlice->getSliceType() != I_SLICE ) { m_pcRateCtrl->getRCGOP()->updateAfterPicture( actualTotalBits ); } else // for intra picture, the estimated bits are used to update the current status in the GOP { m_pcRateCtrl->getRCGOP()->updateAfterPicture( estimatedBits ); } The function ""m_pcRateCtrl->getRCPic()->updateAfterPicture()"" will call ""updateAlphaBetaIntra(&alpha, &beta);"" in turn. The function ""updateAlphaBetaIntra()"" is defined as: Void TEncRCPic::updateAlphaBetaIntra(Double *alpha, Double *beta) { '''Double lnbpp = log(pow(m_totalCostIntra / (Double)m_numberOfPixel, BETA1));''' Double diffLambda = (*beta)*(log((Double)m_picActualBits)-log((Double)m_targetBits)); diffLambda = Clip3(-0.125, 0.125, 0.25*diffLambda); *alpha = (*alpha) * exp(diffLambda); *beta = (*beta) + diffLambda / lnbpp; } Note that for the first I frame the variable ""m_totalCostIntra"" is not properly initialized. The following configuration file is used: #======== File I/O =============== InputFile : E:\\RaceHorses_832x480.yuv InputBitDepth : 8 # Input bitdepth InputChromaFormat : 420 # Ratio of luminance to chrominance samples FrameRate : 25 # Frame Rate per second FrameSkip : 0 # Number of frames to be skipped in input SourceWidth : 832 # Input frame width SourceHeight : 480 # Input frame height FramesToBeEncoded : 50 # Number of frames to be coded Level : 4.1 #======== File I/O ===================== BitstreamFile : E:\\test.265 ReconFile : E:\\test_rec.yuv #======== Profile ================ Profile : main #======== Unit definition ================ MaxCUWidth : 64 # Maximum coding unit width in pixel MaxCUHeight : 64 # Maximum coding unit height in pixel MaxPartitionDepth : 4 # Maximum coding unit depth QuadtreeTULog2MaxSize : 5 # Log2 of maximum transform size for # quadtree-based TU coding (2...6) QuadtreeTULog2MinSize : 2 # Log2 of minimum transform size for # quadtree-based TU coding (2...6) QuadtreeTUMaxDepthInter : 1 QuadtreeTUMaxDepthIntra : 1 #======== Coding Structure ============= IntraPeriod : 20 # Period of I-Frame ( -1 = only first) DecodingRefreshType : 2 # Random Accesss 0:none, 1:CRA, 2:IDR, 3:Recovery Point SEI GOPSize : 4 # GOP Size (number of B slice = GOPSize-1) # Type POC QPoffset QPfactor tcOffsetDiv2 betaOffsetDiv2 temporal_id #ref_pics_active #ref_pics reference pictures predict deltaRPS #ref_idcs reference idcs Frame1: P 4 1 0.3536 0 0 0 1 1 -4 0 Frame2: B 1 2 0.442 0 0 0 1 2 -1 3 0 Frame3: B 2 3 0.442 0 0 0 1 2 -2 2 0 Frame4: B 3 4 0.442 0 0 0 1 2 -3 1 0 #=========== Motion Search ============= FastSearch : 1 # 0:Full search 1:TZ search SearchRange : 64 # (0: Search range is a Full frame) BipredSearchRange : 4 # Search range for bi-prediction refinement HadamardME : 1 # Use of hadamard measure for fractional ME FEN : 1 # Fast encoder decision FDM : 1 # Fast Decision for Merge RD cost #======== Quantization ============= QP : 32 # Quantization parameter(0-51) MaxDeltaQP : 0 # CU-based multi-QP optimization MaxCuDQPDepth : 0 # Max depth of a minimum CuDQP for sub-LCU-level delta QP DeltaQpRD : 0 # Slice-based multi-QP optimization RDOQ : 1 # RDOQ RDOQTS : 1 # RDOQ for transform skip #=========== Deblock Filter ============ DeblockingFilterControlPresent: 0 # Dbl control params present (0=not present, 1=present) LoopFilterOffsetInPPS : 0 # Dbl params: 0=varying params in SliceHeader, param = base_param + GOP_offset_param; 1=constant params in PPS, param = base_param) LoopFilterDisable : 0 # Disable deblocking filter (0=Filter, 1=No Filter) LoopFilterBetaOffset_div2 : 0 # base_param: -6 ~ 6 LoopFilterTcOffset_div2 : 0 # base_param: -6 ~ 6 DeblockingFilterMetric : 0 # blockiness metric (automatically configures deblocking parameters in bitstream) #=========== Misc. ============ InternalBitDepth : 8 # codec operating bit-depth #=========== Coding Tools ================= SAO : 0 # Sample adaptive offset (0: OFF, 1: ON) AMP : 0 # Asymmetric motion partitions (0: OFF, 1: ON) TransformSkip : 0 # Transform skipping (0: OFF, 1: ON) TransformSkipFast : 1 # Fast Transform skipping (0: OFF, 1: ON) SAOLcuBoundary : 0 # SAOLcuBoundary using non-deblocked pixels (0: OFF, 1: ON) #============ Slices ================ SliceMode : 0 # 0: Disable all slice options. # 1: Enforce maximum number of LCU in an slice, # 2: Enforce maximum number of bytes in an 'slice' # 3: Enforce maximum number of tiles in a slice SliceArgument : 1500 # Argument for 'SliceMode'. # If SliceMode==1 it represents max. SliceGranularity-sized blocks per slice. # If SliceMode==2 it represents max. bytes per slice. # If SliceMode==3 it represents max. tiles per slice. LFCrossSliceBoundaryFlag : 1 # In-loop filtering, including ALF and DB, is across or not across slice boundary. # 0:not across, 1: across #============ PCM ================ PCMEnabledFlag : 0 # 0: No PCM mode PCMLog2MaxSize : 5 # Log2 of maximum PCM block size. PCMLog2MinSize : 3 # Log2 of minimum PCM block size. PCMInputBitDepthFlag : 1 # 0: PCM bit-depth is internal bit-depth. 1: PCM bit-depth is input bit-depth. PCMFilterDisableFlag : 0 # 0: Enable loop filtering on I_PCM samples. 1: Disable loop filtering on I_PCM samples. #============ Tiles ================ TileUniformSpacing : 0 # 0: the column boundaries are indicated by TileColumnWidth array, the row boundaries are indicated by TileRowHeight array # 1: the column and row boundaries are distributed uniformly NumTileColumnsMinus1 : 0 # Number of tile columns in a picture minus 1 TileColumnWidthArray : 2 3 # Array containing tile column width values in units of CTU (from left to right in picture) NumTileRowsMinus1 : 0 # Number of tile rows in a picture minus 1 TileRowHeightArray : 2 # Array containing tile row height values in units of CTU (from top to bottom in picture) LFCrossTileBoundaryFlag : 1 # In-loop filtering is across or not across tile boundary. # 0:not across, 1: across #============ WaveFront ================ WaveFrontSynchro : 0 # 0: No WaveFront synchronisation (WaveFrontSubstreams must be 1 in this case). # >0: WaveFront synchronises with the LCU above and to the right by this many LCUs. #=========== Quantization Matrix ================= ScalingList : 0 # ScalingList 0 : off, 1 : default, 2 : file read ScalingListFile : scaling_list.txt # Scaling List file name. If file is not exist, use Default Matrix. #============ Lossless ================ TransquantBypassEnableFlag : 0 # Value of PPS flag. CUTransquantBypassFlagForce: 0 # Force transquant bypass mode, when transquant_bypass_enable_flag is enabled #============ Rate Control ====================== RateControl : 1 # Rate control: enable rate control TargetBitrate : 1000000 # Rate control: target bitrate, in bps KeepHierarchicalBit : 0 # Rate control: 0: equal bit allocation; 1: fixed ratio bit allocation; 2: adaptive ratio bit allocation LCULevelRateControl : 0 # Rate control: 1: LCU level RC; 0: picture level RC RCLCUSeparateModel : 0 # Rate control: use LCU level separate R-lambda model InitialQP : 32 # Rate control: initial QP RCForceIntraQP : 0 # Rate control: force intra QP to be equal to initial QP ### DO NOT ADD ANYTHING BELOW THIS LINE ### ### DO NOT DELETE THE EMPTY LINE BELOW ### " llzzyynjupt HM-14.0 1277 DPB size in HM HM HM-14.0 defect new 2014-04-15T03:08:47+02:00 2014-09-12T16:17:10+02:00 "The following code exists in the HM decoder in TDecTop::xGetNewPicBuffer: {{{ if ( !bBufferIsAvailable ) { //There is no room for this picture, either because of faulty encoder or dropped NAL. Extend the buffer. m_iMaxRefPicNum++; rpcPic = new TComPic(); m_cListPic.pushBack( rpcPic ); } }}} It basically allocates memory more than the size indicated by the DPB, which should not be permitted. It is particularly significant in testing bitstream conformance, to ensure that a bitstream does not accidentally exceed the signalled DPB size but HM decoder doesn't catch it. " adarsh HM-14.0 1278 PSNR for fields HM HM-14.0 defect ksuehring closed 2014-04-16T08:13:47+02:00 2014-10-10T19:29:32+02:00 "It seems PSNR data is not collected properly in HM14.0 Function: xCalculateAddPSNR Input resolution: 1920x1080 isinterlaced : Yes Issue: iHeight value comes as 536 in place of 540. " Mrigen HM-14.0 1279 Frame level PSNR for interlaced sequence. HM HM-14.0 defect ksuehring closed 2014-04-16T11:35:13+02:00 2014-10-10T19:29:32+02:00 "Function: xCalculateInterlacedAddPSNR Issue: Wrong frame size(iSize). Probable Fix: change Int iSize = iWidth*iHeight; To Int iSize = iWidth*(iHeight<<1);" Mrigen HM-14.0 1280 Missing argument HM HM-14.0 defect closed 2014-04-16T11:47:46+02:00 2014-09-12T17:59:51+02:00 "Function: printSummaryOutInterlaced Issue: Said function require one input argument. Probable fix: change from #if _SUMMARY_OUT_ m_gcAnalyzeAll_in.printSummaryOutInterlaced(); #endif To #if _SUMMARY_OUT_ m_gcAnalyzeAll_in.printSummaryOutInterlaced(m_gcAnalyzeAll.getBits()); #endif " Mrigen HM-14.0 1282 Frame level PSNR function for fields HM HM-14.0 defect ksuehring closed 2014-04-16T14:17:03+02:00 2014-10-10T19:22:18+02:00 "Function: xCalculateInterlacedAddPSNR Issue: Condition to call this function is not correct. Test case: Gop period is 32. Interlaced frame related PSNR data collection should happen after POC 17 but it happens after POC 16 itself. Some condition should be added based on ""IRAPtoReorder"" flag" Mrigen HM-14.0 1287 Encoder: sps_max_dec_pic_buffering_minus1 may be set too low HM HM-14.0 defect new 2014-04-25T20:00:21+02:00 2014-04-25T20:03:19+02:00 "With non-CTC GOP configurations the value set for sps_max_dec_pic_buffering_minus1 may be set too low. sps_max_dec_pic_buffering_minus1 is currently based independently on the number of reference frames and the number of frames required for reordering. In GOP structures where different pictures are required for reference and reordering, the resulting value is too low. (e.g. a hierarchical GOP that only uses tid0 pictures as reference) No error is output while encoding, and the reconstructed YUV file contains all pictures in input order. In combination with #1286 this results in encoder-decoder mismatch without any reported error in either encoder or decoder. Possible solutions: 1) improve detection of required sps_max_dec_pic_buffering_minus1 2a) check ordering constraint and give an error, when ascending POC cannot be achieved 2b) allow the user to increase/specify the value of sps_max_dec_pic_buffering_minus1 (which might be complicated because the values exists per temporal ID) " ksuehring HM-14.0 1288 Assertion failed: (uiTemp), function xWriteUvlc... HM HM-14.0 defect closed 2014-04-28T18:02:10+02:00 2014-10-10T16:32:09+02:00 "The noted Assertion occurs when using the cfg in /cfg/misc and interlace content. Please see attached log output. When I use a different reference picture list (see the commented out list in attached cfg) the assertion does not occur. greg" gregcoppa HM-14.0 1289 cbr_flag set by encoder HM HM-14.0 defect ksuehring closed 2014-05-06T17:46:30+02:00 2015-04-02T13:32:54+02:00 "When Timing SEI is enabled, the encoder sets cbr_flag equal to 1 in the VUI. Bit rates are set equal to the bit rate specified for rate control, even if rate control is disabled. There is no mechanism to control the bit rate to match any of the HRD constraints, especially not for cbr_flag equal to 1. HRD checks are missing in general in both encoder and decoder. Conformance of bitstreams cannot be guaranteed unless at least basic checks get implemented." ksuehring HM-14.0 1292 Test Sequences HM HM-14.0 defect closed 2014-06-06T03:01:33+02:00 2014-06-30T17:30:56+02:00 "I can't find the test sequences for which configurations are provided with the encoder. Can you please advice on the location of the test sequences from where they can be downloaded and also include them in the software trunk. It would be a great help to all the people who are using HEVC and trying the benkmark the reults." anujagg85 HM-14.0 1293 Some HRD parameters are not set in decoder when VUI is absent HM HM-14.0 defect closed 2014-06-10T20:39:24+02:00 2014-10-10T16:32:09+02:00 Specification states that initial_cpb_removal_delay_length_minus1, au_cpb_removal_delay_length_minus1 and dpb_output_delay_length_minus1 should be set to 23. But decoder doesn't initialize these fields and they are set to zero by default. This makes it parse BP and PT SEI wrong if VUI information is not specified. gregory HM-14.0 1298 Output value clipping missing from HM RDOQ HM HM-14.0 defect closed 2014-06-26T17:43:51+02:00 2014-10-15T17:45:47+02:00 "Clipping is missing in xRateDistOptQuant in HM & RExt. This means that under specific situations, the encoder can produce coefficient values outside HM's legal range of -32768 to 32767. Here's an example command line for HM, where the first value encountered outside the legal range has the value 37068. ./bin/TAppEncoderStatic -c cfg/encoder_intra_main10.cfg -c cfg/per-sequence/SlideShow.cfg --MaxPartitionDepth=1 --QuadtreeTUMaxDepthIntra=1 --QuadtreeTUMaxDepthInter=1 --RDOQ=1 --TransformSkip=1 --QP=-12 -b str.bin --ConformanceMode=1 -f 1 -fs 3 The problem occurs primarily at negative QPs when large blocks are forced, but if a scaling matrix is used, the problem can occur for more cases. The problem is particularly noticeable in RExt when extended precision processing is not enabled whilst the QP is set to a low value. If RDOQ is disabled, the problem goes away (the values are clipped in xQuant). Possible solution: Add a clip in xRateDistOptQuant in RExt/HM, at the point uiMaxAbsLevel is first calculated, clipping to 32767 (or similar in RExt, based upon extended precision processing) (this will mean that -32768 will never be encountered, but it's quite a limited/rare case) " karlsharman HM-14.0 1304 Unclear decoder DPB behaviour HM HM-14.0 defect new 2014-07-23T09:19:06+02:00 2014-07-29T10:08:18+02:00 "We have generated a simple bitstream using our encoder with the following sequence parameters: sps_max_dec_pic_buffering_minus1 = 3 ( = DPB size 4 ) sps_max_num_reorder_pics = 2 sps_max_latency_increase_plus1 = 0 The stream has a GOP structure like this: Decode Order: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 POC: 0 4 2 1 3 8 6 5 7 12 10 9 11 16 13 13 15 Decoding the stream with HM-15.0 produces the following output ( MD5 values removed ): HM software: Decoder Version [15.0][Windows][VS 1600][64 bit] POC 0 TId: 0 ( I-SLICE, QP 25 ) [DT 0.015] [L0 ] [L1 ] [MD5:,(OK)] POC 4 TId: 0 ( B-SLICE, QP 25 ) [DT 0.042] [L0 0 ] [L1 0 ] [MD5:,(OK)] POC 2 TId: 0 ( B-SLICE, QP 25 ) [DT 0.006] [L0 0 4 ] [L1 4 0 ] [MD5:,(OK)] POC 1 TId: 0 ( B-SLICE, QP 25 ) [DT 0.006] [L0 0 2 4 ] [L1 2 4 0 ] [MD5:,(OK)] POC 3 TId: 0 ( B-SLICE, QP 39 ) [DT 0.013] [L0 2 0 4 ] [L1 4 2 0 ] [MD5:,(OK)] POC 8 TId: 0 ( B-SLICE, QP 40 ) [DT 0.004] [L0 4 2 0 ] [L1 4 2 0 ] [MD5:,(OK)] POC 6 TId: 0 ( B-SLICE, QP 39 ) [DT 0.036] [L0 4 2 8 ] [L1 8 4 2 ] [MD5:,(OK)] POC 5 TId: 0 ( B-SLICE, QP 38 ) [DT 0.003] [L0 4 6 8 ] [L1 6 8 4 ] [MD5:,(OK)] POC 7 TId: 0 ( B-SLICE, QP 39 ) [DT 0.003] [L0 6 4 8 ] [L1 8 6 4 ] [MD5:,(OK)] POC 12 TId: 0 ( B-SLICE, QP 38 ) [DT 0.005] [L0 8 6 4 ] [L1 8 6 4 ] [MD5:,(OK)] POC 10 TId: 0 ( B-SLICE, QP 39 ) [DT 0.004] [L0 8 6 12 ] [L1 12 8 6 ] [MD5:,(OK)] POC 9 TId: 0 ( B-SLICE, QP 39 ) [DT 0.017] [L0 8 10 12 ] [L1 10 12 8 ] [MD5:,(OK)] POC 11 TId: 0 ( B-SLICE, QP 38 ) [DT 0.004] [L0 10 8 12 ] [L1 12 10 8 ] [MD5:,(OK)] POC 16 TId: 0 ( B-SLICE, QP 36 ) [DT 0.006] [L0 12 10 8 ] [L1 12 10 8 ] [MD5:,(OK)] POC 14 TId: 0 ( B-SLICE, QP 37 ) [DT 0.005] [L0 12 10 16 ] [L1 16 12 10 ] [MD5:,(OK)] POC 13 TId: 0 ( B-SLICE, QP 37 ) [DT 0.005] [L0 12 14 16 ] [L1 14 16 12 ] [MD5:,(OK)] POC 15 TId: 0 ( B-SLICE, QP 37 ) [DT 0.004] [L0 14 12 16 ] [L1 16 14 12 ] [MD5:,(OK)] Total Time: 0.215 sec. For the picture with POC=8 the HM decoder executes the following code in TDecTop::xGetNewPicBuffer: {{{ if ( !bBufferIsAvailable ) { //There is no room for this picture, either because of faulty encoder or dropped NAL. Extend the buffer. m_iMaxRefPicNum++; rpcPic = new TComPic(); m_cListPic.pushBack( rpcPic ); } }}} The comment in the source code suggests a fault in our encoder. The RPS for the picture with POC=8 is as follows: Number of Negative Pictures: 3 Delta POCs: -4 -6 -8 Number of Positive Pictures: 0 No Longterm. At this point ( before the execution of the code ) the decoder DPB contains the following 4 pictures: 0: POC=0, Referenced=true, Needed for Output = false 1: POC=2, Referenced=true, Needed for Output = false 2: POC=3, Referenced=false, Needed for Output = true 3: POC=4, Referenced=true, Needed for Output = true The previous picture output by the decoder had POC=2. We are currently interpetrating the point of code to be in the decode process after parsing the slice header of the first slice of the picture with POC=8 but before decoding of the picture with POC=8. ( The RPS has already been applied ). We are currently also considering the possibility that the HM-15.0 decoder slightly inaccurate because, if the full output and removal of pictures from the DPB process of C.5.2.2 had been applied after the application of the RPS but before the call to TDecTop::xGetNewPicBuffer, we believe the picture with POC=3 might has been output and removed from the DPB. We find this a possibility because C.5.2.2 states that for the non IRAP picture case the bumping process in C.5.2.4 is invoked if the number of pictures in the DPB is greater than or equal to sps_max_dec_pic_buffering_minus1 + 1, which, so we think, should have output the picture with POC=3 and marked it as not needed for output so it is removed from the DPB. We tested this hypothesis in a somewhat crude way by calling the TAppDecTop::xWriteOutput method from inside TDecTop::xDecodeSlice after the call to m_apcSlicePilot->applyReferencePictureSet(m_cListPic, m_apcSlicePilot->getRPS()); but before the call to xGetNewPicBuffer (m_apcSlicePilot, pcPic); and, for this case, checking in xWriteOutput for dpbFullness >= maxDecPicBufferingHighestTid. The result of this experiment is that the picture with POC=3 is output by the call to xWriteOutput() and removed from the DPB after applying the RPS of the picture with POC=8. The modified decoder also did not execute the code in question above for the whole sequence. Creating a stream with the standard HM configuration files for random access and a sequence like so: ""TAppEncoder -c encoder_randomaccess_main.cfg -c Kimono.cfg"" also results in a stream that let the decoder execute the code in question. So if our assumption is correct the decoder seems to be implementing the bumping/output process of pictures from the DPB slightly inefficiently and might confuse people looking for a reference example. " ralfw HM-14.0 1323 No slice-protection for deltaQP HM HM-14.0 defect closed 2014-09-12T13:29:24+02:00 2014-10-10T16:32:09+02:00 "The software is missing slice protection for deltaQP prediction value. See TComDataCU::getLastCodedQP, where there are checks if previous CTU (in encoding order) is from the same tile or wavefront-row, but not from the same slice. (There is also a problem regarding wavefronts+tiles). See Section 8.6.1 Derivation process for quantization parameters. Affects decoder and encoder (and therefore no-mismatch noticed). " karlsharman HM-14.0 1326 Bug in Encode Parameter check HM HM-14.0 defect ksuehring closed 2014-10-08T19:48:08+02:00 2014-10-10T18:18:15+02:00 "Here the description of error is matching with text from hevc spec ""'''The variable Log2MinTrafoSize is set equal to log2_min_transform_block_size_minus2 + 2. The bitstream shall not contain data that result in Log2MinTrafoSize greater than or equal to MinCbLog2SizeY'''"" The following code snippet from \source\App\TAppEncoder\TAppEncCfg.cpp xConfirmPara( ( 1 << m_uiQuadtreeTULog2MinSize ) > ( m_uiMaxCUWidth >> m_uiMaxCUDepth ), ""Minimum CU width must be greater than minimum transform size."" ); xConfirmPara( ( 1 << m_uiQuadtreeTULog2MinSize ) > ( m_uiMaxCUHeight >> m_uiMaxCUDepth ), ""Minimum CU height must be greater than minimum transform size."" ); these checks are failing when Minimum CU width/Minimum CU height and minimum transform size are both equal. " ssatavalekar HM-14.0 1283 check remaining bytes of slice segment data HM HM-14.0 enhancement closed 2014-04-18T14:02:58+02:00 2014-10-15T17:43:08+02:00 The spec requires that once decoding end_of_slice_segment_flag with value 1, the remaining bytes in the slice segment data must not be different from zero. The attached patch adds this check. PhuongNguyen HM-14.0 1286 Decoder: output order not checked HM HM-14.0 task new 2014-04-25T19:46:50+02:00 2014-04-25T19:46:50+02:00 "After applying the fix for #1261 the decoder now bumps based on the value of sps_max_dec_pic_buffering_minus1. In bitstreams where sps_max_dec_pic_buffering_minus1 is set too low, pictures can be output that have a higher POC than the picture currently being decoded. The HM decoder does not detect that (error) situation and silently keeps the pictures with POC lower than the last output POC in the DPB unless the DPB gets flushed in the end. The decoded Hash SEI checksums are reported to be correct and there is no error given at all. A check should be added to the HM decoder and an error message should be printed." ksuehring HM-13.0 1233 HM decoder hang under Mac OSX 10.9 HM HM-13.0 defect closed 2014-01-30T22:37:08+01:00 2014-03-25T16:29:27+01:00 "HM decoder always hangs at the end of the bitstream if the decoder is compiled under Mac OSX 10.9 & Xcode 5.0. Seems because of different behaviors of header files in OSX 10.9 and previous versions." zyf674 HM-13.0 1261 HM decoder does not use HighestTID nor sps_max_num_reorder_pics when bumping HM HM-13.0 defect closed 2014-03-11T10:04:44+01:00 2014-04-11T11:08:45+02:00 "The HM decoder is not output order conforming. One reason is that sps_max_dec_pic_buffering_minus1 is not used for determining what pictures to output as specified in section C.5.2.2. Another reason is HM uses sps_max_num_reorder_pics[t_id] instead of sps_max_num_reorder_pics[HighestTid] for determining whether pictures should be output. " rickard HM-13.0 1232 Compatibility for all intra HM-11.0 bitstreams (wrong POC number) HM HM-13.0 defect closed 2014-01-30T17:38:39+01:00 2014-01-31T00:24:48+01:00 "On the HM-13.0 decoder, the NAL unit type for intra slices in all intra configuration of the HM-11.0 bitstreams are decoded as NAL_UNIT_CODED_SLICE_TRAIL_N as specified in the JCTVC K1003-v7 document. However, the m_prevTid0POC private member of TComSlice class is not update for this NAL unit type. This implies in an error when the POC is set in the TDecCavlc::parseSliceHeader function (TDecCAVLC - line 865) when the POC number reaches 129 ( > iMaxPOClsb / 2 ). The slice POC is set as a negative number and the decoder crashes in the function TComSlice::checkLeadingPictureRestrictions (TComSlice - line 805). One simple solution could be modify the function setPOC (TComSlice.h - line 1269) by adding the possibility to update the m_prevTid0POC private member for the NAL unit type NAL_UNIT_CODED_SLICE_TRAIL_N. The attached patch can be used to fix this issue: {{{ Index: Lib/TLibCommon/TComSlice.h =================================================================== --- Lib/TLibCommon/TComSlice.h (revision 3801) +++ Lib/TLibCommon/TComSlice.h (working copy) @@ -1266,7 +1266,7 @@ Void setReferenced(Bool b) { m_bRefenced = b; } Bool isReferenced() { return m_bRefenced; } Bool isReferenceNalu() { return ((getNalUnitType() <= NAL_UNIT_RESERVED_VCL_R15) && (getNalUnitType()%2 != 0)) || ((getNalUnitType() >= NAL_UNIT_CODED_SLICE_BLA_W_LP) && (getNalUnitType() <= NAL_UNIT_RESERVED_IRAP_VCL23) ); } - Void setPOC ( Int i ) { m_iPOC = i; if ((getTLayer()==0) && (isReferenceNalu() && (getNalUnitType()!=NAL_UNIT_CODED_SLICE_RASL_R)&& (getNalUnitType()!=NAL_UNIT_CODED_SLICE_RADL_R))) {m_prevTid0POC=i;} } + Void setPOC ( Int i ) { m_iPOC = i; if ((getTLayer()==0) && ((isReferenceNalu() && (getNalUnitType()!=NAL_UNIT_CODED_SLICE_RASL_R) && (getNalUnitType()!=NAL_UNIT_CODED_SLICE_RADL_R)) || (getNalUnitType()==NAL_UNIT_CODED_SLICE_TRAIL_N))) {m_prevTid0POC=i;} } Void setNalUnitType ( NalUnitType e ) { m_eNalUnitType = e; } NalUnitType getNalUnitType () const { return m_eNalUnitType; } Bool getRapPicFlag (); }}} " dfsouza HM-13.0 1239 MAX_TLAYER should be 7 HM HM-13.0 defect closed 2014-02-07T04:07:10+01:00 2014-02-11T20:06:17+01:00 "The maximum number of temporal layers (MAX_TLAYER) is currently defined as 8. It should be 7, as the bitstream can only have at most 7 sub-layers. The attached patch enables this change, and related clean-up. " adarsh HM-13.0 1240 ADAPTIVE_QP_SELECTION 0 gives build error HM HM-13.0 defect closed 2014-02-07T07:01:12+01:00 2014-02-11T20:33:39+01:00 "Setting ADAPTIVE_QP_SELECTION to 0 gives build error. The patch is attached. Btw, it seems in spite of the macro is set to 1, the method does not work by default. Is it an intended behavior of encoder?" kolya HM-13.0 1241 redundant verification code HM HM-13.0 defect closed 2014-02-07T08:44:20+01:00 2014-02-11T20:08:25+01:00 "on line 4456 of TEncSearch there is a verification code that contains call to obsolete encodeCoeff function. Btw, check always fails. #if 0 // check { m_pcEntropyCoder->resetBits(); m_pcEntropyCoder->encodeCoeff( pcCU, 0, pcCU->getDepth(0), pcCU->getWidth(0), pcCU->getHeight(0) ); const UInt uiBitsForCoeff = m_pcEntropyCoder->getNumberOfWrittenBits(); m_pcRDGoOnSbacCoder->load( m_pppcRDSbacCoder[pcCU->getDepth(0)][CI_CURR_BEST] ); if( uiBitsForCoeff != uiBits ) assert( 0 ); } #endif" kolya HM-13.0 1244 Derivation of POC when CRA has NoRaslOutputFlag equal to 1 HM HM-13.0 defect closed 2014-02-14T20:40:28+01:00 2014-02-21T16:42:31+01:00 "When CRA follows an EOS, the variable NoRaslOutputFlag is set to 1 and POC MSB for that CRA shall be set to 0. Currently, this is not implemented yet." hendry HM-13.0 1246 misleading function name HM HM-13.0 defect closed 2014-02-17T13:03:13+01:00 2014-02-21T16:17:38+01:00 "on line 2431 of TEncSearch.cpp there is UInt uiNumPU = pcCU->getNumPartInter(); but this happens inside all intra." kolya HM-13.0 1247 Bugs in tone mapping information SEI HM HM-13.0 defect closed 2014-02-18T07:47:15+01:00 2014-02-21T16:36:33+01:00 "Two bugs are found in the software regarding tone mapping information SEI. 1. When the decoder parses camera_iso_speed_idc, the value is stored in m_cameraIsoSpeedValue. It should be stored in m_cameraIsoSpeedIdc. 2. Two syntax element, exposure_index_idc and exposure_index_value, are missing. In addition, a typo is found in the software manual that the default value of camera_iso_speed_value should be ""400"" to align the HM code (now ""420""). I believe the attached patch includes the fixes." o.nakagami HM-13.0 1248 HM encoder crashes after encoding a few frames of 4K content (3840x2160) HM HM-13.0 defect closed 2014-02-18T23:51:21+01:00 2014-02-19T04:02:26+01:00 "HM encoder (13.0) crashes after encoding a few frames of 4K content (3840x2160x30) (Any 4k content should do, just set resolution to 3840x2160, see attached.) ############################################################ - HM source code SVN: https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk ------------------------------------------------------------------------ r3800 | bossen | 2014-01-22 08:53:58 -0800 (Wed, 22 Jan 2014) | 1 line Change version number to 13.0 ------------------------------------------------------------------------ ############################################################ -- built using HM_vc9.sln on Windows 7. ############################################################ --- Command line: hm13.exe -c encoder_randomaccess_main.cfg -c Duck_qp28.cfg 1. Duck_qp_28.cfg is attached. 2. encoder_randomaccess_main.cfg is from SVN repository. 3. encoder_lowdelay_P_main.cfg also crashes. ############################################################ ---- Result: crashes after encoding 9 frames (randomaccess) or 10 frames (lowdelay_P_main). " xinjun HM-13.0 1250 misleading loop limit HM HM-13.0 defect closed 2014-02-19T13:01:36+01:00 2014-02-21T16:37:33+01:00 in TEncSearch.cpp line 2489 there is numModesForFullRD, but numModesAvailable should be. Control must reach this line only if these two variables are equal. kolya HM-13.0 1251 redundant function HM HM-13.0 defect closed 2014-02-19T19:58:54+01:00 2014-02-21T16:25:55+01:00 function TComPattern::getAdiOrgBuf just returns its argument kolya HM-13.0 1255 Software Manual: Table formatting broken HM HM-13.0 defect closed 2014-02-27T21:34:57+01:00 2014-10-15T17:45:47+02:00 Table 15 (SEI message parameter) renders outside the page borders, probably due to long configuration parameter names. ksuehring HM-13.0 1264 Filler data HM HM-13.0 defect closed 2014-03-25T01:45:35+01:00 2014-03-25T12:41:32+01:00 "It seems that HM13.0 can not decode bitstreams with nal_unit_type = 38 (NAL_UNIT_FILLER_DATA). Please check FILLER_A_Sony_1.zip" teruhiko HM-13.0 1265 Access Unit delimiter and filler data should be parsed HM HM-13.0 defect closed 2014-03-25T13:05:02+01:00 2015-04-02T16:40:47+02:00 The content of access unit delimiters and filler data is ignored in the HM decoder. It should be parsed and checked. ksuehring HM-13.0 1266 C++ istream EOF exception not thrown on OS X 10.9 HM HM-13.0 defect closed 2014-03-25T16:09:44+01:00 2014-03-25T16:29:27+01:00 "When decoding a bitstream on OS X 10.9 with HTM 13.0, the decoder does not terminate as it cannot determine the EOF of the input file stream. The decoder binary is built using the unmodified Xcode project file from the SVN repository. The reason seems to be the libc++ used by the LLVM compiler on OSX 10.9, which does not throw an exception in case of EOF during a read operation on an istream. This behavior can be changed by applying the attached patch." fabianjaeger HM-13.0 1267 Timing SEI encoding fails for more than one temporal layer HM HM-13.0 defect closed 2014-03-29T18:24:50+01:00 2014-03-29T18:26:29+01:00 When timing SEI is enabled with the new random access configuration file that contains two temporal_id values, the encoding fails. ksuehring HM-13.0 1274 Uninitialized variables HM HM-13.0 defect closed 2014-04-08T03:28:33+02:00 2014-10-15T17:43:08+02:00 Some variables in TComSlice are not initialized. The attached patch may fix the problem. libin HM-13.0 1275 fractional bits is not reset HM HM-13.0 defect closed 2014-04-08T03:30:44+02:00 2014-10-15T17:41:10+02:00 fractional bits is not reset when TEncBinCABAC::start() is called. The attached patch may solve the problem. libin HM-13.0 1276 CABAC status is not set correct HM HM-13.0 defect karlsharman closed 2014-04-08T03:32:57+02:00 2015-03-23T20:47:45+01:00 CABAC status is not set properly before and after encoding split flag when performing RDO. The attached patch may fix the problem. libin HM-13.0 1243 preestChromaPredMode is never called HM HM-13.0 enhancement closed 2014-02-12T12:39:02+01:00 2014-11-17T14:58:13+01:00 code from line 1355 to 1358 of TEncCu.cpp never works kolya HM-13.0 1253 TComDataCU::getIntraDirLumaPredictor always returns 3 HM HM-13.0 enhancement closed 2014-02-24T19:02:25+01:00 2014-11-17T15:00:19+01:00 TComDataCU::getIntraDirLumaPredictor always returns 3. Example patch for the sake of more clarity is attached. kolya HM-13.0 1258 Encoder Description + HM : Low PSNR value for Y compared to U and V HM HM-13.0 task closed 2014-03-09T02:08:29+01:00 2014-04-10T14:26:49+02:00 "Hi All, I tried the HM encoder to encode a raw YUV 720p seq using 8Mbps bit rate control and 2nd time using QP as 32 without rate control. But in both cases the Y PSNR is low compared to U and V PSNR. Even after using Cb and Cr QP offset of 5 results were same. Results: Bitrate: 8Mpbs SUMMARY -------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 91 a 8711.4251 30.4983 38.6517 40.0192 QP: 32.00 SUMMARY -------------------------------------------------------- Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR 91 a 8315.6097 29.6090 36.6231 39.1702 Can someone please suggest how to achieve higher Y PSNR compared to U and V ." anujagg85 HM-13.0 1285 HEVC encoder crashes after finishing first GOP HM HM-13.0 task closed 2014-04-24T21:47:11+02:00 2014-04-25T15:00:23+02:00 "When I try encode video 3840x2160 with 32x32 and 16x16 CU with depth 2 and 1 in HEVC Encoder HM 13, the encoder crashes after encoding (POC 0 4 2 1 3). " ahmedomer6 HM-12.1 1209 segmentation fault with custom GOP structure HM HM-12.1 defect closed 2013-12-05T16:45:42+01:00 2014-01-12T18:49:58+01:00 "I get a segmentation fault from encoder when using custom GOP structure. {{{ #======== Coding Structure ============= IntraPeriod : 800 # Period of I-Frame ( -1 = only first) DecodingRefreshType : 1 # Random Accesss 0:none, 1:CDR, 2:IDR GOPSize : 8 # GOP Size (number of B slice = GOPSize-1) # Type POC QPoffset QPfactor tcOffsetDiv2 betaOffsetDiv2 temporal_id #ref_pics_active #ref_pics reference pictures predict deltaRPS #ref_idcs reference idcs Frame1: P 1 0 0.5 0 0 0 0 1 -1 0 Frame2: P 3 0 0.5 0 0 0 1 2 -3 -2 0 Frame3: B 2 0 0.5 0 0 0 1 3 -2 -1 1 0 Frame4: P 8 0 0.5 0 0 0 1 1 -8 0 Frame5: B 4 0 0.5 0 0 0 1 2 -4 4 0 Frame6: P 7 0 0.5 0 0 0 1 1 -3 0 Frame7: B 6 0 0.5 0 0 0 1 2 -2 1 0 Frame8: B 5 0 0.5 0 0 0 1 2 -1 1 0 }}} " dominik.wojt HM-12.1 1221 Reconstructed frame is different between encoder and decoder with specific configure file HM HM-12.1 defect closed 2014-01-09T10:32:28+01:00 2015-02-02T19:38:20+01:00 "Dear all, In some specific encoder configure setting, the reconstructed frames are different. Here is the encoder log: {{{ ... POC 8 TId: 0 ( B-SLICE, nQP 14 QP 14 ) 130696 bits [Y 61.2198 dB U 62.2437 dB V 63.1534 dB] [ET 22 ] [L0 4 3 2 0 ] [L1 4 3 2 0 ] POC 5 TId: 0 ( B-SLICE, nQP 14 QP 14 ) 6376 bits [Y 65.5337 dB U 65.3747 dB V 66.6798 dB] [ET 21 ] [L0 4 3 0 8 ] [L1 8 4 3 0 ] POC 6 TId: 0 ( B-SLICE, nQP 13 QP 13 ) 27984 bits [Y 63.0237 dB U 64.2979 dB V 65.2965 dB] [ET 21 ] [L0 5 4 0 8 ] [L1 8 5 4 0 ] POC 7 TId: 0 ( B-SLICE, nQP 13 QP 13 ) 17792 bits [Y 62.3651 dB U 63.3046 dB V 64.1559 dB] [ET 21 ] [L0 6 4 0 8 ] [L1 8 6 4 0 ] ... }}} '''POC 6''': the PSNR and reconstructed frame is good. But the decoded frame (POC 6) is corruputed. I don't know the issue is related to decoder or encoder. Or the configure is invalid? Thank you in advance for your help PS. I use conformance clip ""SlideShow_1280x720_20.yuv"" to produce the issue." moiamond HM-12.1 1223 No CABAC contexts reset in WPP when slice segments starts on a new row HM HM-12.1 defect closed 2014-01-10T12:42:16+01:00 2014-01-14T20:12:27+01:00 "In WPP mode for CTB at the start of a row CABAC contexts should be loaded from top-right CTB or reset in case top-right CTB is not available (e.g. in a different slice). In case of dependent slice segments reset is done only when top-right CTB is outside of the frame. I attached a 1-frame stream which reproduces this problem and a patch which fixes it for decoder. Looking at the source code I think the same problem exists in encoder." gregory HM-12.1 1210 Mismatch between HM and Spec on clipping interpolated BiDir samples HM HM-12.1 defect closed 2013-12-06T19:20:32+01:00 2014-01-02T15:38:15+01:00 "In TComInterpolationFilter::filter(), when isLast is true, the interpolated samples are clipped with the following code: if ( isLast ) { val = ( val < 0 ) ? 0 : val; val = ( val > maxVal ) ? maxVal : val; } This clipping operation is not in ""8.5.3.3.3 Fractional sample interpolation process"". In rare cases, an interpolated sample can be negative prior to the above clipping, due to negative filter coefficients. In the case of uni-directional prediction, the above clipping is innocuous, because there is equivalent clipping specified during uni-directional weighting. In the case of bi-directional prediction, 2 interpolated samples are added and the result is clipped; see ""8.5.3.3.4 Weighted sample prediction process"", expressions 8-239 and 8-252. If either interpolated sample is negative, there can be a different result depending on if the interpolated sample was clipped in filter() or not. If an encoder ""pre-clips"" and a decoder does not, there can be drift. " stevew HM-12.1 1216 Changes to TComSlice.h required in order to compile with GCC 4.8.1 HM HM-12.1 defect closed 2013-12-19T21:32:52+01:00 2014-01-02T15:36:14+01:00 "Minor Bug Changes to TComSlice.h required in order to compile with GCC 4.8.1 When compiling with GCC 4.8.1 TComSlice.h is flagged up multiple times with a single compiler error (""array subscript is above array bounds""). In effect, the compiler does not like it that tLayer (or tlayer is is called elsewhere) is assumed to be valid, it could be abused and thus unsafe. To resolve this fear, test tLayer against getMaxTLayers to decide if it is safe prior to accepting or reverting to the maximum possible value. e.g. m_numReorderPics[(tLayer = tLayer > getMaxTLayers ()? getMaxTLayers () : tLayer)] = v; Making the following modifications will suppress these errors and the codebase will compile. //------------- // Around Line 450 // Change from //Void setNumReorderPics(UInt v, UInt tLayer) { m_numReorderPics[tLayer] = v; } // To Void setNumReorderPics(UInt v, UInt tLayer) { m_numReorderPics[(tLayer = tLayer > getMaxTLayers ()? getMaxTLayers () : tLayer)] = v; } // Change from //Void setMaxDecPicBuffering(UInt v, UInt tLayer) { m_uiMaxDecPicBuffering[tLayer] = v; } Void setMaxDecPicBuffering(UInt v, UInt tLayer) { m_uiMaxDecPicBuffering[(tLayer = tLayer > getMaxTLayers ()? getMaxTLayers () : tLayer)] = v; } // Change from //Void setMaxLatencyIncrease(UInt v, UInt tLayer) { m_uiMaxLatencyIncrease[tLayer] = v; } // To Void setMaxLatencyIncrease(UInt v, UInt tLayer) { m_uiMaxLatencyIncrease[(tLayer = tLayer > getMaxTLayers ()? getMaxTLayers () : tLayer)] = v; } //------------- //------------- // Around Line 820 // Change from //Void setNumReorderPics(Int i, UInt tlayer) { m_numReorderPics[tlayer] = i; } // To Void setNumReorderPics(Int i, UInt tlayer) { m_numReorderPics[(tlayer = tlayer > getMaxTLayers ()? getMaxTLayers () : tlayer)] = i; } // Change from //Void setMaxDecPicBuffering ( UInt ui, UInt tlayer ) { m_uiMaxDecPicBuffering[tlayer] = ui; } // To Void setMaxDecPicBuffering ( UInt ui, UInt tlayer ) { m_uiMaxDecPicBuffering[(tlayer = tlayer > getMaxTLayers ()? getMaxTLayers () : tlayer)] = ui; } // Change from //Void setMaxLatencyIncrease ( UInt ui , UInt tlayer) { m_uiMaxLatencyIncrease[tlayer] = ui; } // To Void setMaxLatencyIncrease ( UInt ui , UInt tlayer) { m_uiMaxLatencyIncrease[(tlayer = tlayer > getMaxTLayers ()? getMaxTLayers () : tlayer)] = ui; } //-------------" yetish HM-12.1 1217 HM lossless coding search tidy HM HM-12.1 defect closed 2013-12-20T15:29:08+01:00 2014-01-11T19:29:37+01:00 "HM has three command line parameters that control lossless coding, namely: LosslessCuEnabled TransquantBypassEnableFlag CUTransquantBypassFlagValue There is some confusion over how these are used, probably because LosslessCuEnabled appears to have once been an SPS setting, equivalent to ""qpprime_y_zero_transquant_bypass_flag"". (There is even a place in TEncSearch where the value of QP' is checked to see if it is 0) The flag was removed from the SPS, replaced with the transquant-bypass-enable flag in the PPS (and a per CU flag). In HM, LosslessCuEnabled causes the search algorithm to consider checking transquant-bypass coding. However, unless TransquantBypassEnableFlag is also set, no per-CU transquant flag is sent. In addition the value of the transquant bypass CU flag is fixed at the value of CUTransquantBypassFlagValue, and is therefore if this is 0, you do not have transquant bypass coding in the search. In RExt, there are just two settings, namely TransquantBypassEnableFlag CUTransquantBypassFlagForce where TransquantBypassEnableFlag enables the tool in the PPS and in the search, including use when maxDeltaQP is non zero. If CUTransquantBypassFlagForce is 1, the transquant-bypass flag is forced to 1 for all CUs, otherwise the best mode is selected by encoder search. When testing transquant-bypass modes, the value of QP used is set to the lowest QP value being tested, not QP'=0, as this reduces delta QP values. The supplied match can be applied to HM12.1 as tagged to make HM use the same lossless coding search algorithm as HM12.1_RExt5.1 (with RExt__BACKWARDS_COMPATIBILITY_HM_TRANSQUANTBYPASS set to 0). " karlsharman HM-12.1 1219 SAO code for different InternalBitDepth(C) HM HM-12.1 defect closed 2013-12-27T07:59:29+01:00 2014-01-29T20:03:38+01:00 "HM-12.1+RExt-5.1 encoder crashes with segmantation fault when InternalBitDepth is less than InternalBitDepthC. It seems that the current SAO code has an issue in the case. By disabling SAO, the encoder works without error. Example of failure: TAppEncoderStatic -c ../cfg/encoder_randomaccess_main_rext.cfg -c ../cfg/per-sequence/BirdsInCage_444_10bit.cfg --InternalBitDepth=8 --InternalBitDepthC=12 It seems the issue is related to #1192 " o.nakagami HM-12.1 1222 adding temporal scalability to random access configuration results in an assert error HM HM-12.1 defect closed 2014-01-10T11:56:00+01:00 2014-01-12T18:29:40+01:00 "encoding with the attached config file(s) results in the following assert in file ""TComSlice.cpp"". assert(rpcPic->getSlice( 0 )->isReferenced()==0||rpcPic->getUsedByCurr()==0||rpcPic->getTLayer()<=this->getTLayer());" wonkap HM-12.1 1224 Slice index setting at decoder HM HM-12.1 defect closed 2014-01-11T18:28:58+01:00 2014-01-11T19:07:37+01:00 "In xDecodeSlice function, there is the following code copying slice info and setting slice index: {{{ m_apcSlicePilot->setSliceIdx(m_uiSliceIdx); if (!m_bFirstSliceInPicture) { m_apcSlicePilot->copySliceInfo( pcPic->getPicSym()->getSlice(m_uiSliceIdx-1) ); } }}} However, in the multi slices case, it will assign the slice index from the previous slice through the copying. So, for example, in two slices case, both slices will have index 0. Probably, the order should be swapped as follows: {{{ if (!m_bFirstSliceInPicture) { m_apcSlicePilot->copySliceInfo( pcPic->getPicSym()->getSlice(m_uiSliceIdx-1) ); } m_apcSlicePilot->setSliceIdx(m_uiSliceIdx); }}}" Vadim HM-12.1 1226 Wrong NAL unit type when TemporalID > 0 HM HM-12.1 defect closed 2014-01-17T03:31:18+01:00 2014-01-17T03:45:54+01:00 "When some pictures are assigned a non-zero temporal ID in the RA configuration, some leading pictures are assigned a NAL unit type of TSA rather than RASL/RADL. The attached configuration file (that is the RA configuration with some easy coding tool parameters) enables the case reported here. The reason for the bug is that the check for TSA/STSA NUT assignment at the encoder happens after the check for leading pictures. However, leading pictures should not be marked as TSA/STSA. The attached patch fixes this by adding a check at the encoder. The attached patch is on top of HM-12.1-dev, r3788. " adarsh HM-12.1 1227 The HM decoder doesn't check the validity of {vps,sps}_num_reorder_pics HM HM-12.1 defect closed 2014-01-18T22:13:34+01:00 2015-02-02T17:44:27+01:00 "According to the specification: {{{ The value of vps_max_num_reorder_pics[ i ] shall be in the range of 0 to vps_max_dec_pic_buffering_minus1[ i ], inclusive. [...] The value of sps_max_num_reorder_pics[ i ] shall be in the range of 0 to sps_max_dec_pic_buffering_minus1[ i ], inclusive. }}} But the HM decoder doesn't check that at all. The attached patch adds assertions for these conditions." Smarter HM-12.1 1229 PSNR computation for Bit_Depths > 8 HM HM-12.1 defect closed 2014-01-27T11:06:25+01:00 2014-10-15T17:59:41+02:00 "During the PSNR computations, the maxvalY and maxvalC are computed as follows - Int maxvalY = 255 << (g_bitDepthY-8); Int maxvalC = 255 << (g_bitDepthC-8); My contention is that they are incorrect and should be computed as Int maxvalY = (1 << g_bitDepthY) - 1; Int maxvalC = (1 << g_bitDepthC) - 1; " gosk_balem HM-12.1 1212 SAD and HAD called during Inter where pixel values may be out of range, negative or exceed upper limit HM HM-12.1 enhancement karlsharman closed 2013-12-09T11:49:42+01:00 2015-03-24T10:37:00+01:00 "Minor Bug SAD and HAD called during Inter where pixel values may be out of range, negative or exceed upper limit of given bit depth due to TComYuv::removeHighFreq(...) Within TEncSearch::xMotionEstimation(..), when bBi is enabled, TcomYuv::removeHighFreq(...) is called which attempts to average out the Dst with the Src pix values as follows: pDst[x ] = (pDst[x ]<<1) - pSrc[x ] ; However, in not all cases are they similar values, and so it is possible to that a negative values or that exceeding the bit-depth range would be stored. Previously, in Ticket 175 the issue was raised that clipping was hindering performance and hence the code checks if the flag for disabling clip has been enabled. #if DISABLING_CLIP_FOR_BIPREDME The issue with clipping is it only stops if it exceeds the bit-depth range and does not handle if the value is negative. As a consequence, when SAD or Hadamard Distortion Metrics are called within TcomRdCost, block pairs may contain invalid pixel values, resulting in lower or highter distortion scores including exceeding the maximum for the given bit depth. As such, for those block pairs that are incorrectly scored, this can affect the choices undertaken by the encoder. Taking observations of when Dst is assigned values that are invalid, test conditions were produced. Src would be assessed against and upper and lower condition in order to decide average out Dst with Src. The condition are linear equations, adding minimal additional complexity. The lower limit test is y > 2x + 1, where x is Dst and Src is y, the upper condition is y <= 2x – 2^BitDepth. int Dst2 = pDst[x]<<1; pDst[x ] = pSrc[x ] > (Dst2 + 1) && pSrc[x] <= Dst2-iMaxValBitDepthY ? Dst2 - pSrc[x ] : pDst[x ]; where iMaxValBitDepthY is defined prior to the loop as: int iMaxValBitDepthY = 2< (DstU2 + 1) && pSrcU[x] <= DstU2-iMaxValBitDepthC ? DstU2 - pSrcU[x ] : pDstU[x ]; pDstV[x ] = pSrcV[x ] > (DstV2 + 1) && pSrcV[x] <= DstV2-iMaxValBitDepthC ? DstV2 - pSrcV[x ] : pDstV[x ]; The solution was tested on the first three frames of an 8 bit, 10 bit and 12 bit video, where no subsequent invalid pixel values captured after new Dst value has been assigned within TcomYuv::removeHighFreq(...). Below is a table of a series of brief tests conducted with the differences between original and that with the modified removeHighFreq() method. A short GOP of 5 was used. Video Resolution BitDepth Frames Bit-Rate Y-PSNR Time RaceHorses 416x240 8 30 1.04% -0.0579 0.49% OldTown 1920x1080 10 20 0.07% -0.0008 -0.48% Traffic 2560x1600 12 10 0.13% 0.001 -0.24% " yetish HM-12.0 1152 TZ algorithm tests MVs outside the search range HM HM-12.0 defect closed 2013-08-22T15:21:05+02:00 2013-09-04T17:23:40+02:00 "The range search is set relative to MV predictor in xMotionEstimation function, but when performing the diamond search in xTZSearch, the start point could be the MV predictor or the zero MV. In the later case, the start point could be outside the search range and some of the diamond points may still be tested. Is this behavior intended ?" mohamed.chibani HM-12.0 1153 Encoder crashes in field based coding with rate control HM HM-12.0 defect new 2013-08-27T14:34:23+02:00 2014-04-10T12:30:28+02:00 "Encoder crashes when FieldCoding and RateControl are both equal to 1. Note: the same problem exists in HM-11.0 with the patch in JCTVC-N0372." kazui HM-12.0 1172 Encoding with IDR period fails HM HM-12.0 defect closed 2013-10-08T17:31:54+02:00 2014-10-15T17:45:47+02:00 "Encoding with IntraPeriod > -1 DecodingRefreshType: 2 fails when checkLeadingPictureRestrictions() is called. At the encoder rcListPic contains entries that are not previously coded pictures where checks are not useful. Easiest fix would probably be to disable the check at the encoder." ksuehring HM-12.0 1194 Difference in neighbor calculation for SAO in HM-11.1 and HM-12.0 HM HM-12.0 defect closed 2013-11-08T14:52:26+01:00 2013-11-08T18:00:30+01:00 "Between HM-11.1 and HM-12.0 function setNDBFilterBlockBorderAvailability was renamed to deriveLoopFilterBoundaryAvailibility in a change set 3543. This change set is based on JCTVC-N0230 which is supposed to be an encoder-only enhancement and only a cleanup of decoder code. But the change also changes logic for determining neighbor CTB across slice boundaries for SAO filter in case of above-right and below-left neighborhood, and therefore affects how decoder applies SAO filter to a frame. Previously value of flag slice_loop_filter_across_slices_enabled_flag was always taken from the later slice in the encoding order. But in HM-12.0 when slices for current and neighbor CTB are different, code compares slice start blocks in raster order. When tiles are enabled, CTB with bigger tile scan address may have a smaller raster scan address, and when values of slice_loop_filter_across_slices_enabled_flag are different, decoder may work differently than in HM-11.1 version. Attached is a patch that fixes this behavior for decoder and uses tile scan. If necessary I can attach streams that show that HM-12.x decoder behaves differently from previous versions." gregory HM-12.0 1197 decoder crashes with CBR streams HM HM-12.0 defect closed 2013-11-12T14:10:49+01:00 2014-10-15T17:43:08+02:00 Decoder crashes with CBR streams. This occurs because NAL_UNIT_FILLER_DATA are not parsed by the decoder. zagyo HM-12.0 1198 HM Decoder does not handle decoding of a SAFF stream HM HM-12.0 defect closed 2013-11-12T22:20:45+01:00 2015-03-26T15:59:08+01:00 "the HM decoder is not able to decode in an uninterrupted manner a SAFF (Sequence Adaptive Field Frame) stream. Decoders can decode a Frame based stream and it has modifications to decode a field stream, but it doesn't have capabilities to decode a stream that switches from frame to field (or vice versa). " YSyed HM-12.0 1143 Field-coding - memory leak HM HM-12.0 defect closed 2013-08-20T10:49:31+02:00 2013-08-20T23:08:25+02:00 "Memory leak in TEncTop::encode line 477. Bug detected during RExt development. " karlsharman HM-12.0 1144 field-coding preanalyze called with uninitialized data HM HM-12.0 defect closed 2013-08-20T10:53:18+02:00 2013-08-20T23:12:13+02:00 "Preanalyze called twice on uninitialized data in TEncTop::encode. Bug detected during RExt development. " karlsharman HM-12.0 1145 Field-coding - odd-number of fields per GOP and intra-only processing HM HM-12.0 defect new 2013-08-20T13:08:12+02:00 2014-04-10T12:30:28+02:00 "Several problems fixed in supplied patch: 1/ If GOP size is an odd number of fields, it will never output more than the first picture. 2/ If intra-only coding, the system does not work. 3/ If coding of more than 8 bit, the interlaced PSNRs are incorrect - remove UChar casting in reinterleave function. 4/ Fixes spacing in output text info. Bugs detected during RExt development. " karlsharman HM-12.0 1146 Field-coding - randomaccess intra-period assertion HM HM-12.0 defect closed 2013-08-20T13:13:23+02:00 2014-01-17T20:50:47+01:00 "Asserts (using the randomaccess_field_coding.cfg) at the field with POC=intra-period, because there is a POC with number intra-period+1 in the buffers (the second of the pair). Fails with assertion: ""TComSlice.cpp:879 Void TComSlice::checkLeadingPictureRestrictions(TComList&): Assertion `rpcPic->getPOC() < this->getPOC()' failed."" eg the following 25 frame (50 field) simulation fails, but 24 frames is ok: ./bin/TAppEncoderStatic -c cfg/encoder_randomaccess_field_coding.cfg -c cfg/per-sequence/BasketballPass.cfg -o enc.yuv -ip 48 -q 32 -f 25 --SEIpictureDigest=1 -b bin.bin --RDOQ=0 --RDOQTS=0 --SAO=0 Bug detected during RExt development. " karlsharman HM-12.0 1147 SAO buffer-overrun (and field-coding) HM HM-12.0 defect closed 2013-08-20T13:27:14+02:00 2013-09-04T16:26:47+02:00 "SAO has currently a maximum of 4 temporal layers, and the supplied field-coding randomaccess configuration needs 5. SAO should be updated for more flexibility (eg making m_depthSaoRate a vector). Meanwhile, an assertion should be added to prevent buffer-overruns from being silent. In the current 12.0-dev branch, add: assert(depth<4); after line 3345 in rdoSaoUnitAll (prior to writing to member variable m_depthSaoRate) " karlsharman HM-12.0 1148 Field-coding - incorrect depth calculation HM HM-12.0 defect closed 2013-08-20T16:31:00+02:00 2014-03-26T13:48:25+01:00 "The depth calculation in TEncSlice::initEncSlice appears to be wrong for field-coding. You get (for randomaccess_field_coding) in decoding order Field Depth QP Expected Depth 0 0 (base) 0 1 4 +1 0 16 0 +1 0 17 4 +1 0 8 1 +2 1 9 4 +2 1 4 2 +3 2 5 4 +3 2 2 2 +3 3 3 4 +4 3 6 2 +3 3 7 4 +4 3 etc i.e. all odd fields have depth of 4, and a depth of 4 will be seen before a depth of 3, 2 or 1 has even been processed. " karlsharman HM-12.0 1161 cannot decode some conformance streams HM HM-12.0 defect closed 2013-09-07T01:31:10+02:00 2013-09-07T02:26:40+02:00 "I observe HM-12.0 decoder crash on the following streams from the draft_conformance folder: - NUT_A_ericsson_4 - SLIST_B_Sony_8 - SLIST_D_Sony_9 I have checked out from tags/HM-12.0 head revision, OS Windows 7 /x64, MS Visual C++ 200 Command line: TAppDecoder.exe -b slist_b_sony_8.bit -o out.yuv Getting assertion ""list iterator not dereferencable"" in TAppDecTop.cpp line 249." dlgbrdv@… HM-12.0 1162 something about about delta_poc_s0_minus1 HM HM-12.0 defect closed 2013-09-10T05:11:41+02:00 2014-01-13T01:00:08+01:00 "in hevc spec 7.4.8,about delta_poc_s0_minus1 it wrote ""when i is greater than 0, specifies the difference between the picture order count values of the i-th entry and the ( i + 1 )-th entry in the stRpsIdx-th candidate short-term RPS that have picture order count values less than the picture order count value of the current picture"" but i think when i is greater than 0,delta_poc_s0_minus1 should specify between the picture order count values of the i-th entry and the ( i - 1 )-th entry ?? the above (i+1) have confuse me! " charles.lee HM-12.0 1166 HM12.0 software does not follow encoder configuration for a specific coding structure HM HM-12.0 defect closed 2013-09-23T10:25:03+02:00 2013-10-04T15:19:43+02:00 "Hi, I am trying to code a GOP structure of 4 low-delay-P configuration, where frames 1,2,3 are non-reference frames and frame is 0 a reference frame. Below is the encoder configuration I use: {{{ #======== Coding Structure ============= IntraPeriod : -1 # Period of I-Frame ( -1 = only first) DecodingRefreshType : 0 # Random Accesss 0:none, 1:CDR, 2:IDR GOPSize : 4 # GOP Size (number of B slice = GOPSize-1) # Type POC QPoffset QPfactor tcOffsetDiv2 betaOffsetDiv2 temporal_id #ref_pics_active #ref_pics reference pictures predict deltaRPS #ref_idcs reference idcs Frame1: P 1 2 0.4624 0 0 1 4 4 -1 -5 -9 -13 0 Frame2: P 2 2 0.4624 0 0 1 3 3 -2 -6 -10 1 -1 5 1 1 1 0 0 Frame3: P 3 2 0.4624 0 0 1 3 3 -3 -7 -11 1 -1 4 1 1 1 0 Frame4: P 4 1 0.578 0 0 0 3 3 -4 -8 -12 1 -1 4 1 1 1 0 }}} Generated bitstream differs from the above specified structure in creating reference picture lists in the first two GOPs, frames 2,3,6 and 7. For these frames, the picture lists include additional reference frames. The rest of the bitstream is correct. I'd appreciate your comments in case my configuration is the problem. Below is an example of decoder log file: {{{ POC 0 TId: 0 ( I-SLICE, QP 32 ) [DT 0.016] [L0 ] [L1 ] [:,,,(unk)] POC 1 TId: 1 ( P-SLICE, QP 34 ) [DT 0.015] [L0 0 ] [L1 ] [:,,,(unk)] POC 2 TId: 1 ( P-SLICE, QP 34 ) [DT 0.016] [L0 '''1''' 0 ] [L1 ] [:,,,(unk)] POC 3 TId: 1 ( P-SLICE, QP 34 ) [DT 0.000] [L0 '''2 1''' 0 ] [L1 ] [:,,,(unk)] POC 4 TId: 0 ( P-SLICE, QP 33 ) [DT 0.015] [L0 0 ] [L1 ] [:,,,(unk)] POC 5 TId: 1 ( P-SLICE, QP 34 ) [DT 0.016] [L0 4 0 ] [L1 ] [:,,,(unk)] POC 6 TId: 1 ( P-SLICE, QP 34 ) [DT 0.015] [L0 '''5''' 4 0 ] [L1 ] [:,,,(unk)] POC 7 TId: 1 ( P-SLICE, QP 34 ) [DT 0.000] [L0 '''6''' 4 0 ] [L1 ] [:,,,(unk)] POC 8 TId: 0 ( P-SLICE, QP 33 ) [DT 0.000] [L0 4 0 ] [L1 ] [:,,,(unk)] POC 9 TId: 1 ( P-SLICE, QP 34 ) [DT 0.016] [L0 8 4 0 ] [L1 ] [:,,,(unk)] POC 10 TId: 1 ( P-SLICE, QP 34 ) [DT 0.015] [L0 8 4 0 ] [L1 ] [:,,,(unk)] POC 11 TId: 1 ( P-SLICE, QP 34 ) [DT 0.000] [L0 8 4 0 ] [L1 ] [:,,,(unk)] }}}" bugdayci HM-12.0 1171 Field-coding - bug fix in GOP structure HM HM-12.0 defect closed 2013-10-03T15:57:27+02:00 2014-01-11T18:26:47+01:00 " ( Fixes the bug reported in ticket #1146 ) A normativity problem occurs at each intra period where, after coding the IRAP top field, we try to encode a trailing picture (the bottom field) before the leading pictures associated to the same IRAP picture. In the patch attached, the bottom field is coded before the top field in this case in order to avoid this problem without separating fields of the same frame at each GOP end. " zagyo HM-12.0 1181 Wrong NAL unit type name HM HM-12.0 defect closed 2013-10-16T20:40:48+02:00 2013-10-17T14:20:22+02:00 The NAL unit type for sub-layer reference pictures of type TSA are still named as TLA. The attached patch (in H-M12.0-dev) changes all occurrences of TLA_R to TSA_R. adarsh HM-12.0 1186 Use xCalcHADs2x2 in TComRdCost::calcHAD for sizes not multiple 8 / 4 HM HM-12.0 defect closed 2013-10-21T19:37:59+02:00 2014-01-12T02:36:15+01:00 "The calculation function TComRdCost::calcHAD calls size-specific calculation functions xCalcHADs8x8 for image sizes multiple 8 and xCalcHADs4x4 for sizes multiple 4 but is also using xCalcHADs8x8 for any other size (Line 440 of TComRdCost.cpp) This seems like a bug - the 2x2 specific function xCalcHADs2x2 shall be used instead." UweErikMartin HM-12.0 1188 HM-12.0-dev cannot compile with VS 2013 HM HM-12.0 defect closed 2013-10-28T07:42:10+01:00 2013-10-28T09:26:46+01:00 #include in program_options_lite.cpp will solve the problem. libin HM-12.0 1192 SAO prevents different Chroma QP offsets HM HM-12.0 defect closed 2013-11-04T16:06:05+01:00 2014-01-10T17:50:49+01:00 "The new version of SAO prevents different chroma QP offsets being applied: An assert fails on any test conditions that cause different lambda values between the two chroma channels. Also spelling error of variables - labmda -> lambda. Simple solution being tested in RExt development; patch to follow. Example of failure: ./bin/TAppEncoderStatic -c cfg/encoder_intra_main.cfg -c cfg/per-sequence/BlowingBubbles.cfg -qp 22 -f 1 --SEIDecodedPictureHash=1 -b testStream.bin -o reconstruction.yuv --CrQpOffset=1 " karlsharman HM-12.0 1193 syntax ordering in buffering period SEI HM HM-12.0 defect closed 2013-11-07T09:11:47+01:00 2014-01-11T18:40:17+01:00 "It seems there is syntax ordering inconsistency in buffering period SEI between JCTVC-O0054_v1 and HM-12.1-dev (rev3662). In JCTVC-O0054_v1, ... if( irap_cpb_params_present_flag ) { cpb_delay_offset dpb_delay_offset } concatenation_flag au_cpb_removal_delay_delta_minus1 ... However, in HM-12.1-dev, ... concatenation_flag au_cpb_removal_delay_delta_minus1 if( irap_cpb_params_present_flag ) { cpb_delay_offset dpb_delay_offset } ... Suggested fix is attached. (The ordering in the softare is modified to align the text.) " o.nakagami HM-12.0 1195 Disabling RDO HM HM-12.0 defect closed 2013-11-09T07:49:28+01:00 2013-11-13T10:21:36+01:00 "I have tried disabling RDO by using the cmd line flag ""SBACRD"" and set it to false for running the encoder. But then it crashes while running. Please provide a fix for this problem. " benravin HM-12.0 1196 HM Release mode HM HM-12.0 defect closed 2013-11-09T07:52:07+01:00 2013-11-12T22:34:48+01:00 How reliable is using HM software built in release mode ? Any know issues in using release mode for testing. benravin HM-12.0 1199 May a mismatch between HEVC spec and HM on clip of qPiCb HM HM-12.0 defect closed 2013-11-20T15:52:07+01:00 2013-11-22T19:23:39+01:00 "In spec, qPiCb = Clip3( −QpBdOffsetC, 57, QpY + pps_cb_qp_offset + slice_cb_qp_offset ) (8-260), In HM software(HM12.1), #define QpUV(iQpY) ( ((iQpY) < 0) ? (iQpY) : (((iQpY) > 57) ? ((iQpY)-6) : g_aucChromaScale[(iQpY)]) ) It seems no clip operation in the HM software." C.Lai HM-12.0 1207 Bad copyToPic partition implementation in encoder HM HM-12.0 defect closed 2013-11-28T13:19:44+01:00 2014-10-28T18:45:20+01:00 " It seems as though the partition-based copyToPic does not copy the correct information -- it only copies the source side from partition 0, although the destination side (in the pic) represents the desired partition. Looking at classD random access, the encoder results are not affected. The bad picture data are not used during encoder decisions, and are later overwritten with a CU-based copyToPic that is correct. The attached patch fixes the source offset. " gordon HM-12.0 1211 HEVC parallel HM HM-12.0 defect jimmy closed 2013-12-07T07:18:46+01:00 2013-12-09T03:48:13+01:00 "Dear I am a PH.D of Tongji university of China. Now I am researching the Parallelism of HEVC in TOKUSHIMA university. You know that the parallel base the HM-12.0 test model is very low.So this is my interest point. But now i met a problem. In the HM-12.0 test model, the function --- Void TEncCu::xCompressCU( TComDataCU*& rpcBestCU, TComDataCU*& rpcTempCU, UInt uiDepth, PartSize eParentPartSize ), is a recursive call, which is to compress a CU block recursively with enabling sub-LCU-level delta QP. I don't know how to make this function a non-recursive function. If you give me some advise , i will thank you very much. Best wish jimmy" jimmy HM-12.0 1220 GOP Structure HM HM-12.0 defect closed 2014-01-07T10:11:07+01:00 2014-01-13T01:05:21+01:00 "Dear all, I cannot generate a personalized GOP structure working with HM encoder. Would you please provide me an example having 3 types I/P/B of frame in GOP. I wonder why in the data structure of GOPEntry, the type of deltaRPS is a simple integer and not an array of integer. I misunderstand something here? Thank you in advance for your help " soq2000 HM-12.0 1149 Check to see whether disabling SAO at picture-level produces the lowest cost HM HM-12.0 enhancement closed 2013-08-20T18:52:03+02:00 2014-10-15T17:43:08+02:00 "SAO currently does not check whether disabling at the picture-level results in the lowest cost. Currently, only per-LCU disabling is tested. Simple patch tests total cost of using SAO, and if it is positive, disables SAO at the picture-level. " karlsharman HM-12.0 1157 detect forbidden sequence in NAL unit HM HM-12.0 enhancement closed 2013-09-02T14:54:23+02:00 2014-01-11T18:45:26+01:00 "The section 7.4.2.1 in the text mentions forbidden sequences in NAL unit : Within the NAL unit, any four-byte sequence that starts with 0x000003 other than the following sequences shall not occur at any byte-aligned position: – 0x00000300 – 0x00000301 – 0x00000302 – 0x00000303 The attached patch adds the corresponding detection in the reference software." PhuongNguyen HM-12.0 1154 something about about sps_max_dec_pic_buffering_minus1 HM HM-12.0 task closed 2013-08-29T07:31:22+02:00 2013-08-29T12:51:29+02:00 "In the hevc specification about sps_max_dec_pic_buffering_minus1, it wrote ""The value of sps_max_dec_pic_buffering_minus1[ i ] shall be less than or equal to vps_max_dec_pic_buffering_minus1[ i ] for each value of i "" .but i think the two parameter will be equal for rach value of i , i have a doubt abut it ? who can explain it? " charles.lee HM-12.0 1165 something about the inter prediction for spatial merging candidates HM HM-12.0 task closed 2013-09-23T08:43:10+02:00 2014-01-11T19:10:12+01:00 charles.lee HM-12.0 1168 typo in the name of the function HM HM-12.0 defect closed 2013-09-25T03:00:28+02:00 2013-09-25T12:30:57+02:00 "In TComSlice.cpp we can find function named ""processDefaultMarix"", which should be ""processDefaultMatrix"". " kazushi HM-12.0 1150 Code tidy - missing inclusion guards on header files HM HM-12.0 enhancement closed 2013-08-21T10:58:40+02:00 2014-10-15T17:45:47+02:00 "The following header files are missing their inclusion guards: (Lib/libmd5/libmd5.h) (Lib/libmd5/MD5.h) Lib/TLibCommon/NAL.h Lib/TLibCommon/AccessUnit.h Lib/TLibCommon/SEI.h Lib/TLibEncoder/AnnexBwrite.h Lib/TLibEncoder/NALwrite.h Lib/TLibEncoder/SEIwrite.h Lib/TAppCommon/program_options_lite.h Lib/TLibDecoder/AnnexBread.h Lib/TLibDecoder/NALread.h Also, some other header files do not use the common HM naming for their guard macro: i.e. _ _ _ _ " karlsharman HM-12.0 1191 Difference between the binaries obtained from release mode and debug mode. HM HM-12.0 task closed 2013-10-31T17:05:22+01:00 2013-11-05T21:37:11+01:00 "Hi, i was conducting some tests on HM12 codec and i used executables generated in debug mode on Visual Studios 2012, which are slow and therefore I am planning to use the the executables generated by release mode. Are there any possibility of difference between the encoded bins obtained by encoding using HM12 exes in debug mode and the encoded bins in release mode. Are both same? Thanks for the help." pratyush HM-11.0 1190 Field decoding is not working fine HM HM-11.0 defect closed 2013-10-31T14:47:15+01:00 2014-01-17T20:59:49+01:00 "Hi, In HM 11.0 version Field decoding output is visually not good. I have attached the encoder config file from which the stream generated. when i decode the stream field_seq_flag is always zero for pic_struct 1 or 2 which is conflict with the spec ""Table D.2 – Interpretation of pic_struct"". In the encoder code field_seq_flag is always set to false. " satish HM-11.0 1121 HighestTid should be used instead of t_id for bumping HM HM-11.0 defect closed 2013-07-12T17:42:54+02:00 2014-04-11T11:08:45+02:00 "C.5.2.2 specifies among other things that bumping shall continue until the following condition becomes false: ""The number of pictures in the DPB that are marked as ""needed for output"" is greater than sps_max_num_reorder_pics[ HighestTid ]"" The HM code looks at sps_max_num_reorder_pics[temporal_id of the current NAL] instead of sps_max_num_reorder_pics[HighestTid]. This leads to pictures being output in incorrect order, for instance in this example with pictures listed in decoding order: sps_max_num_reorder_pics[0]=0 sps_max_num_reorder_pics[1]=1 sps_max_num_reorder_pics[2]=2 sps_max_num_reorder_pics[2]=4 Note that 4 is needed here IDR POC=0 t_id=0 TRAIL_R POC=8 t_id=0 TRAIL_R POC=4 t_id=1 TRAIL_R POC=2 t_id=2 HM bumps this picture too soon TRAIL_R POC=6 t_id=2 TRAIL_N POC=1 t_id=3 TRAIL_N POC=3 t_id=3 TRAIL_N POC=5 t_id=3 TRAIL_N POC=7 t_id=3 " rickard HM-11.0 1127 Default intra configuration generates non-conforming bitstreams HM HM-11.0 defect closed 2013-07-31T15:02:32+02:00 2013-08-01T20:44:03+02:00 "The default intra configuration (in cfg/encoder_intra_main.cfg) generates one IDR picture followed by ""intra pictures"" with NAL unit type 0 (non-reference pictures). This creates an issue with the POC value associated with picture 129 and following: the POC of picture 129 is coded as -127. The encoder should be fixed, for example by using NAL unit type 1 for ""intra pictures"" in this encoder configuration." fbossen HM-11.0 1128 checkLeadingPictureRestrictions fails HM HM-11.0 defect closed 2013-07-31T15:07:41+02:00 2013-07-31T15:09:08+02:00 r3529 introduced the TComSlice::checkLeadingPictureRestrictions function. Assert statements fail on first picture when using default configuration files. fbossen HM-11.0 1129 assertion failure in TComSlice::checkLeadingPictureRestrictions HM HM-11.0 defect closed 2013-08-04T23:40:57+02:00 2013-08-04T23:41:40+02:00 "Assertion fails in TComSlice::checkLeadingPictureRestrictions when using default RA configuration with r3535. " fbossen HM-11.0 1130 decoder segmentation fault when decoding RAP_B_Bossen_1.bin HM HM-11.0 defect closed 2013-08-07T20:27:56+02:00 2013-08-13T16:48:59+02:00 "The decoder stops with a segmentation fault when decoding conformance bitstream RAP_B_Bossen_1.bin. Segmentation fault is caused by an attempt to free a NULL pointer. Proposed patch is attached." dthoang HM-11.0 1113 Incorrect handling of mismatch between reference pictures and reference idcs HM HM-11.0 defect closed 2013-07-01T15:01:10+02:00 2013-07-23T22:22:59+02:00 "There is the following code fragment in the file TEncTop.cpp near the line 800: if (numNeg != rps->getNumberOfNegativePictures()) { printf(""Warning: number of negative pictures in RPS is different between intra and inter RPS specified in the config file.\n""); rps->setNumberOfNegativePictures(numNeg); rps->setNumberOfPositivePictures(numNeg+numPos); } if (numPos != rps->getNumberOfPositivePictures()) { printf(""Warning: number of positive pictures in RPS is different between intra and inter RPS specified in the config file.\n""); rps->setNumberOfPositivePictures(numPos); rps->setNumberOfPositivePictures(numNeg+numPos); } Looks like it should be: if (numNeg != rps->getNumberOfNegativePictures()) { printf(""Warning: number of negative pictures in RPS is different between intra and inter RPS specified in the config file.\n""); rps->setNumberOfNegativePictures(numNeg); rps->setNumberOfPictures(numNeg+numPos); } if (numPos != rps->getNumberOfPositivePictures()) { printf(""Warning: number of positive pictures in RPS is different between intra and inter RPS specified in the config file.\n""); rps->setNumberOfPositivePictures(numPos); rps->setNumberOfPictures(numNeg+numPos); }" avoronov HM-11.0 1116 Some conditions from section 8.3.1 missing in POC decoding routine HM HM-11.0 defect closed 2013-07-05T10:17:41+02:00 2013-07-05T11:26:39+02:00 "Section 8.3.1 of the spec states: Let prevTid0Pic be the previous picture in decoding order that has TemporalId equal to 0 and that is not a RASL picture, a RADL picture, or a sub-layer non-reference picture. The relevant line in the reference decoder is in TComSlice.h: {{{ Void setPOC( Int i ) { m_iPOC = i; if(getTLayer()==0) m_prevPOC=i; } }}} This misses out the RASL, RASL or sub-layer non-reference condition. I think this should be changed to: {{{ Void setPOC( Int i ) { m_iPOC = i; if(getTLayer()==0 && !isRASL() && !isRADL() && !isNonReference()) m_prevPOC=i; } Bool isRASL() const { return (getNalUnitType() == NAL_UNIT_CODED_SLICE_RASL_N) || (getNalUnitType() == NAL_UNIT_CODED_SLICE_RASL_R); } Bool isRADL() const { return (getNalUnitType() == NAL_UNIT_CODED_SLICE_RADL_N) || (getNalUnitType() == NAL_UNIT_CODED_SLICE_RADL_R); } Bool isNonReference() const { return (getNalUnitType() == NAL_UNIT_CODED_SLICE_RADL_N) || (getNalUnitType() == NAL_UNIT_CODED_SLICE_RASL_N) || (getNalUnitType() == NAL_UNIT_CODED_SLICE_STSA_N) || (getNalUnitType() == NAL_UNIT_CODED_SLICE_TRAIL_N) || (getNalUnitType() == NAL_UNIT_CODED_SLICE_TSA_N) ; } }}}" jackh HM-11.0 1117 ljj HM HM-11.0 defect closed 2013-07-08T09:33:35+02:00 2013-07-08T17:55:36+02:00 ljjly HM-11.0 1119 Incorrect DeltaPocMsbCycleLt Calculation in HM-11.0 HM HM-11.0 defect closed 2013-07-12T02:09:25+02:00 2013-07-23T22:10:36+02:00 "When delta_poc_msb_cycle_lt[i] is not present, it is inferred to be equal to 0. Therefore, based on the following formula, for the first LTRP specified in the slice header (i = num_long_term_sps), the variable DeltaPocMsbCycleLt[i] should be reset to 0 if delta_poc_msb_present_flag[i] = 0. if( i == 0 | | i == num_long_term_sps ) DeltaPocMsbCycleLt[i] = delta_poc_msb_cycle_lt[i] else DeltaPocMsbCycleLt[i] = delta_poc_msb_cycle_lt[i] + DeltaPocMsbCycleLt[i − 1] The attached patch can be used to fix this issue in HM-11.0. " bheng HM-11.0 1123 Small memory leak in the decoder HM HM-11.0 defect closed 2013-07-18T16:44:57+02:00 2013-07-23T22:34:11+02:00 "Dear Experts, There is a small memory leak in the HM 11.0 decoder when it is decoding the SEI messages. ||'''File:'''||/source/Lib/TLibDecoder/SEIread.cpp|| ||'''Function:'''||Void SEIReader::xReadSEImessage(SEIMessages& seis, const NalUnitType nalUnitType, TComSPS *sps)|| ||'''Problem:'''||m_fifo is not freed.|| '''Solution:''' Add {{{ #!cpp getBitstream()->deleteFifo(); }}} before {{{ #!cpp delete getBitstream(); }}} in the line 317 of the SEIread.cpp source file. [[BR]] Best regards, Diego Felix de Souza Ph.D. Student -- Electrical Engineering Instituto Superior Técnico INESC-ID Rua Alves Redol, 9 1000-029 Lisboa -- Portugal" dfsouza HM-11.0 1124 Incorrect POC LSB Calculation HM HM-11.0 defect closed 2013-07-21T01:51:01+02:00 2013-07-23T22:13:47+02:00 "The modulus (%) operator in C will incorrectly compute POC LSB when the POC value is negative. The attached patch is one way to fix the issue. " bheng HM-11.0 1125 Incorrect POC in RASL pictures with dependent slice segments. HM HM-11.0 defect closed 2013-07-21T17:48:07+02:00 2013-07-23T22:55:24+02:00 "The POC values for dependent slice segments in RASL pictures are incorrectly initialized when the associated independent slice segments have been skipped due to random access or a broken link. These incorrect POC values can cause HM to attempt to decode the dependent slice segments when they should be skipped like the other slices in the picture. I believe the attached patch would be one way to fix this issue. This may or may not also resolve the issue reported in Ticket #1088. " bheng HM-11.0 1126 Conformance checks of leading pictures are missing HM HM-11.0 defect closed 2013-07-23T16:38:04+02:00 2013-07-24T17:44:55+02:00 The HM decoder does not check for the on leading picture restrictions that are specified in section 7.4.2.2 NAL unit header semantics. rickard HM-11.0 1132 incorrect decoded picture buffer reordering with IDR HM HM-11.0 defect closed 2013-08-10T11:13:10+02:00 2014-01-13T18:40:23+01:00 "The HM11.0 decoder seems to not correctly reorder the decoded pictures buffer (DPB) when more than an IDR picture is present in a sequence. With the attached configuration file (which produces the sequence IDR-P-IDR), the encoder DPB correctly reorder the pictures as 0-1-2. By decoding the bitstream generated by the encoder, the decoder reconstructed sequence is not matching the encoder due to the wrong reordering 2-0-1. The HM11.0rc1 was used for both the encoder and decoder." stefano913 HM-11.0 1141 Incorrect levels in configuration files HM HM-11.0 defect closed 2013-08-19T10:56:33+02:00 2013-09-04T16:38:24+02:00 Kimono and ParkScene config files have a level of '4.0', which cannot be interpreted by HM; level '4' can be used instead. karlsharman HM-11.0 1156 Temporal motion vector prediction HM HM-11.0 defect siva sree closed 2013-08-31T09:54:38+02:00 2013-09-04T16:41:41+02:00 "in the section 8.5.3.2.7 of ITU-T H.265 (04/2013), derivation of bottom right block location is explained as below 2. The bottom right collocated motion vector is derived as follows: xColBr = xPb + nPbW (8-173) yColBr = yPb + nPbH (8-174) If yPb >> CtbLog2SizeY is equal to yColBr >> CtbLog2SizeY, yColBr is less than pic_height_in_luma_samples, and xColBr is less than pic_width_in_luma_samples, the following applies: – The variable colPb specifies the luma prediction block covering the modified location given by ( ( xColBr >> 4 ) << 4, ( yColBr >> 4 ) << 4 ) inside the collocated picture specified by colPic so, here ( ( xColBr >> 4 ) << 4, ( yColBr >> 4 ) << 4 ) means rounding off the collocated co-ordinates to the multiples of 16 but its not happening in the implementation " sivasree HM-11.0 1242 Issues due to strict compile checking - HM11.0 HM HM-11.0 defect N Vijay Anand closed 2014-02-11T08:03:44+01:00 2014-02-12T15:24:55+01:00 "Im using HM11.0 release version. I've used strict compile settings and see decoder crashes. I'm using arm-xilinx-linux-gnueabi-g++ (Sourcery CodeBench Lite 2012.09-104) 4.7.2 compiler. 1. Line #391, TComRom.cpp file "" UInt log2Blk = g_aucConvertToBit[ uiNumBlkSide ] + 1;"" The array g_aucConvertToBit is of type Char and initialised to -1. Desired value in log2Blk is 0, but compiler is putting 256. Changing UInt log2Blk to UChar log2Blk fixes the issue. 2. In file TComMotionInfo.h, class TComMvField { private: TComMv m_acMv; Int m_iRefIdx; ... } Same issue with parameter m_iRefIdx. Somewhere in code it's initialised by -1, but value returned when queried is 255. Changing m_iRefIdx from Int to Char recursively in code fixes the issue. 3. I think there are host of other clean compilation issues, but they aren't causing crashes. Thanks, Vijay " elenva HM-11.0 1111 New encoder parameter: Disable Intra in Inter HM HM-11.0 enhancement karlsharman closed 2013-06-19T12:42:59+02:00 2015-03-23T20:08:46+01:00 "For testdata generation it is sometimes usefull to disable all intra coding units in inter slices in the encoder. The JM encoder has a parameter called ""DisableIntraInInter"". " engelhardt HM-11.0 1112 WS cleanup HM HM-11.0 enhancement closed 2013-06-28T22:37:13+02:00 2013-07-01T18:44:43+02:00 "An enormous amount of trailing whitespace present in the codebase. Attached patch takes care of that. Patch against commit on trunk {{{ 2820ce9ee717f520cade57fb3bd71532d1eae544 }}} {{{ $ git diff --stat trunk build/linux/app/TAppDecoder/makefile | 2 +- build/linux/lib/TLibVideoIO/makefile | 8 +- build/linux/makefile | 2 +- build/linux/utils/annexBbytecount/makefile | 2 +- build/linux/utils/convert_NtoMbit_YCbCr/makefile | 2 +- cfg/encoder_intra_main.cfg | 8 +- cfg/encoder_intra_main10.cfg | 8 +- cfg/encoder_lowdelay_P_main.cfg | 8 +- cfg/encoder_lowdelay_P_main10.cfg | 8 +- cfg/encoder_lowdelay_main.cfg | 8 +- cfg/encoder_lowdelay_main10.cfg | 8 +- cfg/encoder_randomaccess_main.cfg | 12 +- cfg/encoder_randomaccess_main10.cfg | 12 +- doc/mainpage.h | 6 +- doc/software-manual.tex | 88 ++++---- source/App/TAppDecoder/TAppDecCfg.cpp | 2 +- source/App/TAppDecoder/TAppDecCfg.h | 8 +- source/App/TAppDecoder/TAppDecTop.cpp | 40 ++-- source/App/TAppDecoder/TAppDecTop.h | 12 +- source/App/TAppDecoder/decmain.cpp | 2 +- source/App/TAppEncoder/TAppEncCfg.cpp | 138 ++++++------ source/App/TAppEncoder/TAppEncCfg.h | 34 +-- source/App/TAppEncoder/TAppEncTop.cpp | 72 +++--- source/App/TAppEncoder/TAppEncTop.h | 18 +- source/App/TAppEncoder/encmain.cpp | 2 +- source/App/utils/BitrateTargeting/ExtractBitrates.cpp | 44 ++-- source/App/utils/BitrateTargeting/ExtractBitrates.h | 8 +- source/App/utils/BitrateTargeting/ExtractBitratesMain.cpp | 12 +- source/App/utils/BitrateTargeting/GuessLambdaModifiers.cpp | 70 +++--- source/App/utils/BitrateTargeting/GuessLambdaModifiers.h | 2 +- source/App/utils/BitrateTargeting/GuessLambdaModifiersMain.cpp | 10 +- source/App/utils/BitrateTargeting/RuntimeError.h | 8 +- source/App/utils/BitrateTargeting/encodeCommand.sh | 8 +- source/App/utils/BitrateTargeting/makefile | 2 +- source/App/utils/BitrateTargeting/targetBitrates.sh | 42 ++-- source/App/utils/annexBbytecount.cpp | 2 +- source/App/utils/convert_NtoMbit_YCbCr.cpp | 6 +- source/Lib/TAppCommon/program_options_lite.cpp | 36 +-- source/Lib/TAppCommon/program_options_lite.h | 52 ++--- source/Lib/TLibCommon/AccessUnit.h | 2 +- source/Lib/TLibCommon/CommonDef.h | 10 +- source/Lib/TLibCommon/ContextModel.cpp | 2 +- source/Lib/TLibCommon/ContextModel.h | 16 +- source/Lib/TLibCommon/ContextModel3DBuffer.cpp | 4 +- source/Lib/TLibCommon/ContextModel3DBuffer.h | 10 +- source/Lib/TLibCommon/ContextTables.h | 260 +++++++++++----------- source/Lib/TLibCommon/NAL.h | 2 +- source/Lib/TLibCommon/SEI.cpp | 6 +- source/Lib/TLibCommon/SEI.h | 16 +- source/Lib/TLibCommon/TComBitCounter.h | 6 +- source/Lib/TLibCommon/TComBitStream.cpp | 4 +- source/Lib/TLibCommon/TComBitStream.h | 6 +- source/Lib/TLibCommon/TComCABACTables.cpp | 2 +- source/Lib/TLibCommon/TComCABACTables.h | 2 +- source/Lib/TLibCommon/TComDataCU.cpp | 542 +++++++++++++++++++++++----------------------- source/Lib/TLibCommon/TComDataCU.h | 148 ++++++------- source/Lib/TLibCommon/TComInterpolationFilter.cpp | 46 ++-- source/Lib/TLibCommon/TComInterpolationFilter.h | 6 +- source/Lib/TLibCommon/TComList.h | 14 +- source/Lib/TLibCommon/TComLoopFilter.cpp | 122 +++++------ source/Lib/TLibCommon/TComLoopFilter.h | 22 +- source/Lib/TLibCommon/TComMotionInfo.cpp | 34 +-- source/Lib/TLibCommon/TComMotionInfo.h | 36 +-- source/Lib/TLibCommon/TComMv.h | 38 ++-- source/Lib/TLibCommon/TComPattern.cpp | 70 +++--- source/Lib/TLibCommon/TComPattern.h | 30 +-- source/Lib/TLibCommon/TComPic.cpp | 26 +-- source/Lib/TLibCommon/TComPic.h | 32 +-- source/Lib/TLibCommon/TComPicSym.cpp | 32 +-- source/Lib/TLibCommon/TComPicSym.h | 22 +- source/Lib/TLibCommon/TComPicYuv.cpp | 74 +++---- source/Lib/TLibCommon/TComPicYuv.h | 54 ++--- source/Lib/TLibCommon/TComPrediction.cpp | 52 ++--- source/Lib/TLibCommon/TComPrediction.h | 26 +-- source/Lib/TLibCommon/TComRdCost.cpp | 278 ++++++++++++------------ source/Lib/TLibCommon/TComRdCost.h | 46 ++-- source/Lib/TLibCommon/TComRdCostWeightPrediction.cpp | 82 +++---- source/Lib/TLibCommon/TComRdCostWeightPrediction.h | 8 +- source/Lib/TLibCommon/TComRom.cpp | 40 ++-- source/Lib/TLibCommon/TComRom.h | 30 +-- source/Lib/TLibCommon/TComSampleAdaptiveOffset.cpp | 108 ++++----- source/Lib/TLibCommon/TComSampleAdaptiveOffset.h | 8 +- source/Lib/TLibCommon/TComSlice.cpp | 166 +++++++------- source/Lib/TLibCommon/TComSlice.h | 150 ++++++------- source/Lib/TLibCommon/TComTrQuant.cpp | 458 +++++++++++++++++++-------------------- source/Lib/TLibCommon/TComTrQuant.h | 96 ++++---- source/Lib/TLibCommon/TComWeightPrediction.cpp | 32 +-- source/Lib/TLibCommon/TComWeightPrediction.h | 4 +- source/Lib/TLibCommon/TComYuv.cpp | 112 +++++----- source/Lib/TLibCommon/TComYuv.h | 56 ++--- source/Lib/TLibCommon/TypeDef.h | 28 +-- source/Lib/TLibDecoder/AnnexBread.cpp | 4 +- source/Lib/TLibDecoder/NALread.cpp | 10 +- source/Lib/TLibDecoder/SEIread.cpp | 34 +-- source/Lib/TLibDecoder/SyntaxElementParser.cpp | 12 +- source/Lib/TLibDecoder/SyntaxElementParser.h | 2 +- source/Lib/TLibDecoder/TDecBinCoder.h | 4 +- source/Lib/TLibDecoder/TDecBinCoderCABAC.cpp | 38 ++-- source/Lib/TLibDecoder/TDecBinCoderCABAC.h | 12 +- source/Lib/TLibDecoder/TDecCAVLC.cpp | 162 +++++++------- source/Lib/TLibDecoder/TDecCAVLC.h | 18 +- source/Lib/TLibDecoder/TDecCu.cpp | 132 +++++------ source/Lib/TLibDecoder/TDecCu.h | 28 +-- source/Lib/TLibDecoder/TDecEntropy.cpp | 52 ++--- source/Lib/TLibDecoder/TDecEntropy.h | 42 ++-- source/Lib/TLibDecoder/TDecGop.cpp | 18 +- source/Lib/TLibDecoder/TDecGop.h | 18 +- source/Lib/TLibDecoder/TDecSbac.cpp | 150 ++++++------- source/Lib/TLibDecoder/TDecSbac.h | 30 +-- source/Lib/TLibDecoder/TDecSlice.cpp | 28 +-- source/Lib/TLibDecoder/TDecSlice.h | 10 +- source/Lib/TLibDecoder/TDecTop.cpp | 86 ++++---- source/Lib/TLibDecoder/TDecTop.h | 12 +- source/Lib/TLibEncoder/SEIwrite.cpp | 16 +- source/Lib/TLibEncoder/SyntaxElementWriter.cpp | 18 +- source/Lib/TLibEncoder/SyntaxElementWriter.h | 2 +- source/Lib/TLibEncoder/TEncAnalyze.cpp | 2 +- source/Lib/TLibEncoder/TEncAnalyze.h | 30 +-- source/Lib/TLibEncoder/TEncBinCoder.h | 4 +- source/Lib/TLibEncoder/TEncBinCoderCABAC.cpp | 40 ++-- source/Lib/TLibEncoder/TEncBinCoderCABAC.h | 18 +- source/Lib/TLibEncoder/TEncBinCoderCABACCounter.cpp | 4 +- source/Lib/TLibEncoder/TEncBinCoderCABACCounter.h | 6 +- source/Lib/TLibEncoder/TEncCavlc.cpp | 104 ++++----- source/Lib/TLibEncoder/TEncCavlc.h | 22 +- source/Lib/TLibEncoder/TEncCfg.h | 60 ++--- source/Lib/TLibEncoder/TEncCu.cpp | 186 ++++++++-------- source/Lib/TLibEncoder/TEncCu.h | 34 +-- source/Lib/TLibEncoder/TEncEntropy.cpp | 42 ++-- source/Lib/TLibEncoder/TEncEntropy.h | 24 +- source/Lib/TLibEncoder/TEncGOP.cpp | 270 +++++++++++------------ source/Lib/TLibEncoder/TEncGOP.h | 26 +-- source/Lib/TLibEncoder/TEncPic.cpp | 8 +- source/Lib/TLibEncoder/TEncPic.h | 4 +- source/Lib/TLibEncoder/TEncPreanalyzer.cpp | 2 +- source/Lib/TLibEncoder/TEncPreanalyzer.h | 2 +- source/Lib/TLibEncoder/TEncRateCtrl.cpp | 86 ++++---- source/Lib/TLibEncoder/TEncRateCtrl.h | 22 +- source/Lib/TLibEncoder/TEncSampleAdaptiveOffset.cpp | 262 +++++++++++----------- source/Lib/TLibEncoder/TEncSampleAdaptiveOffset.h | 30 +-- source/Lib/TLibEncoder/TEncSbac.cpp | 146 ++++++------- source/Lib/TLibEncoder/TEncSbac.h | 36 +-- source/Lib/TLibEncoder/TEncSearch.cpp | 962 ++++++++++++++++++++++++++++++++++++++++----------------------------------------- source/Lib/TLibEncoder/TEncSearch.h | 150 ++++++------- source/Lib/TLibEncoder/TEncSlice.cpp | 190 ++++++++-------- source/Lib/TLibEncoder/TEncSlice.h | 20 +- source/Lib/TLibEncoder/TEncTop.cpp | 86 ++++---- source/Lib/TLibEncoder/TEncTop.h | 26 +-- source/Lib/TLibEncoder/WeightPredAnalysis.cpp | 30 +-- source/Lib/TLibEncoder/WeightPredAnalysis.h | 2 +- source/Lib/TLibVideoIO/TVideoIOYuv.cpp | 30 +-- source/Lib/TLibVideoIO/TVideoIOYuv.h | 12 +- source/Lib/libmd5/MD5.h | 2 +- source/Lib/libmd5/libmd5.h | 2 +- 154 files changed, 4104 insertions(+), 4104 deletions(-) }}}" fredrikpihl HM-11.0 1120 check syntax elements to match profile and level requirements HM HM-11.0 enhancement closed 2013-07-12T14:32:38+02:00 2014-01-13T18:35:24+01:00 "The spec requires limits for syntax elements in a given profile or level. For instance, for level 5 and higher levels, the value of CtbSizeY must be equal to 32 or 64. It will be very helpful to add the checks of these limits in the reference decoder to detect the stream does not violate spec requirements. Best regards, Phuong." PhuongNguyen HM-11.0 1115 Debug display of unsigned elements HM HM-11.0 defect closed 2013-07-03T15:32:25+02:00 2013-07-23T23:12:17+02:00 "In Lib\TLibDecoder\SyntaxElementParser.cpp there are some useful functions that display debugging information about parsed syntax elements. However, sometimes large unsigned elements can be displayed as being negative. I think this is because the fprintf format string uses %d instead of %u. e.g. in `Void SyntaxElementParser::xReadUvlcTr (UInt& rValue, const Char *pSymbolName)` the code reads fprintf( g_hTrace, ""%-50s ue(v) : %d\n"", pSymbolName, rValue ); I think it would be a little nicer if this were changed to fprintf( g_hTrace, ""%-50s ue(v) : %u\n"", pSymbolName, rValue ); " peterderivaz HM-11.0 1118 initPattern uses wrong pixel offsets for boundary calculations, but results are still correct HM HM-11.0 defect closed 2013-07-09T11:51:32+02:00 2014-10-15T17:45:47+02:00 "In TComPattern::initPattern, pcCU->getCUPelX() and Y are used in calculations to determine picture boundaries, but something like pcCU->getPic()->getCU( pcCU->getAddr())->getCUPelX() is the correct thing to use. (A CTU based g_auiRasterToPelX offset is being added to this value.) It seems that the uiOffsetLeft and uiOffsetAbove calculation results don't change with this modification, as we're only interested in determining if we're at picture boundaries which occurs only when everything is zero." gordon HM-11.0 1122 pic_output_flag and no_output_of_prior_pics_flag have no effect on the reference decoder HM HM-11.0 defect closed 2013-07-15T12:20:31+02:00 2014-02-09T01:15:01+01:00 " The reference code does not seem to discard pictures with pic_output_flag==0 or correctly handle the discard of pictures in the DPB when it encounters an IRAP picture with NoRaslOutputFlag==1 and no_output_of_prior_pics_flag==1. Is this intended behaviour (on the grounds that it is more helpful for a reference decoder to output all decoded pictures even if they are not meant to be shown)? Apologies if these small points appear pedantic - the reason we are interested is because at Argon Design we have made HEVC test streams, taking in all points of the spec, including the flags mentioned above. We test by matching md5 checksums of YUV output between the reference decoder and the decoder under test, hence the discovery of this issue. " jackh HM-10.1 1106 Candidate for prevTid0Pic HM HM-10.1 defect closed 2013-06-07T12:24:54+02:00 2013-07-05T11:26:40+02:00 " In 8.3.1, there is the following sentence. "" - Let prevTid0Pic be the previous picture in decoding order that has TemporalId equal to 0 and that is not a RASL picture, a RADL picture, or a sub-layer non-reference picture. "" This means the following picture can not be the prevTid0Pic - TemporalId is not equal to 0 or - RASL, RADL, sub-layer non-reference picture But HM10.1 seems that all pictures are candidate of prevTid0Pic." teruhiko HM-10.1 1108 No implementation of DPB dumping when encountering a new CVS starting with a CRA picture HM HM-10.1 defect closed 2013-06-11T11:02:56+02:00 2014-02-12T15:12:24+01:00 "The spec, section C.3.2, says: If the current picture is a CRA picture ''[with NoRaslOutputFlag equal to 1]'', NoOutputOfPriorPicsFlag is set equal to 1 (regardless of the value of no_output_of_prior_pics_flag). So when a new CVS is encountered whose first picture is a CRA picture, the tail end of the previous CVS is dumped without output. The reference decoder doesn't appear to implement this rule. I'm also somewhat confused as to why this rule exists - why particularly would you want to dump the contents of the DPB in this situation?" jackh HM-10.1 1109 Reference decoder doesn't take sps_max_latency_increase_plus1 into account when outputting pictures HM HM-10.1 defect new 2013-06-11T15:44:38+02:00 2013-06-11T15:44:38+02:00 This parameter is not used at all by the reference decoder in determining picture output order. This is not an issue unless the decoder's output is to be compared for verification purposes with another built according to spec section C.5.2.2, in which case some pictures will be output in a different order. jackh HM-10.0 1012 HM10.0 does not decode bitstreams starting with a CRA. HM HM-10.0 defect closed 2013-02-20T09:03:35+01:00 2013-03-05T12:26:57+01:00 "HM software: Decoder Version [10.0][Mac OS X][GCC 4.2.1][64 bit] Warning: tried to activate PPS referring to a inactive SPS at non-IDR.Parameter set activation failed!" tktan HM-10.0 1054 Decoder bug when pictures share the same POC lsb HM HM-10.0 defect closed 2013-03-28T16:18:27+01:00 2013-04-02T23:21:40+02:00 "The decoder does not properly support pictures that share the same POC lsb. If there is a long-term picture with the same POC lsb as the current picture it can happen that the decoder puts the current picture in the reference picture list which results in incorrect decoding. The attached patch seems to solve the problem." rickard HM-10.0 1070 HM performs loop filtering after replacing SPS/PPS HM HM-10.0 defect closed 2013-04-10T06:37:19+02:00 2014-11-11T12:02:19+01:00 "In HM-10.0, loop filtering and SEI digest checking is performed after the first slice header of the next picture is decoded. By then, the SPS and PPS needed to deblock & SAO-filter the finished picture may have already been replaced by new ones with the same ID. A patch is attached that fixed the issue. It changes the overal decoder flow a bit: - The slice decode updates a boolean that indicates if the decompressed slice was the last of the pic, as detected by last CU address being equal to numCUsInFrame-1. - If the boolean is true, perform loop filtering. - When SEI digest message arrives, perform the check then. Digest code was moved from TDecGop to TDecTop" pieterkapsenberg HM-10.0 1071 Nonconforming RPS in CRA pictures HM HM-10.0 defect closed 2013-04-11T20:15:22+02:00 2013-05-17T17:15:18+02:00 "It appears that the RPS associated with CRA pictures in the ""random access"" encoder configurations produces a value of NumPocTotalCurr that is nonzero. This doesn't conform to the following restriction expressed in section 8.3.2 of the specification: ""If the current picture is a BLA or CRA picture, the value of NumPocTotalCurr shall be equal to 0."" The RPS associated with CRA pictures should be modified in the HM encoder such that all ""used"" flags are equal to 0." fbossen HM-10.0 1074 Decoder output is wrong for IPBB sequence HM HM-10.0 defect closed 2013-04-18T05:34:32+02:00 2013-04-22T18:31:30+02:00 Decoder output is visually not good for IPBB sequence.But the encoder recon is visually good. satish HM-10.0 1088 Picture buffer not created when first slice segment in a picture is skipped HM HM-10.0 defect closed 2013-05-08T23:48:26+02:00 2013-07-23T22:56:36+02:00 If the first slice segment in a picture is RandomAccessSkipPicture or SkipPictureForBLA, xDecodeSlice() will return false prematurely. Then, if the second slice segment is a dependent slice segment, m_cGopDecoder.decompressSlice() is called without calling xGetNewPicBuffer(). (At this time, the previous picture has not done loop filtering yet.) So this slice segment will write pixels to the previous picture's buffer and corrupt the previous picture. peter HM-10.0 1089 Encoder crashes when using fixed rate and fixed slice length HM HM-10.0 defect closed 2013-05-09T17:51:55+02:00 2013-05-09T19:57:53+02:00 "The variable LCUIdx assumes wrong values when enconding with fixed bitrate and fixed slice length. The solution is the decrease by one the value LCUIdx when a LCU is encoded but not included in the current slice, because it exceeds the maximum size requested (fixed slice length). This is the error: TAppEncoderStatic_HM-10.1-dev_2013_05_09: /home/joaoc/IT/PhD/HEVC/srcHEVC-mirror/build/linux/lib/TLibEncoder/../../../../source/Lib/TLibEncoder/TEncRateCtrl.h:147: TRCParameter TEncRCSeq::getLCUPara(Int, Int): Assertion `LCUIdx < m_numberOfLCU' failed." jfmcarreira HM-10.0 1090 Encoder crashes when using fixed rate and fixed slice length HM HM-10.0 defect closed 2013-05-09T17:52:27+02:00 2013-05-28T17:04:08+02:00 "The variable LCUIdx assumes wrong values when enconding with fixed bitrate and fixed slice length. The solution is the decrease by one the value LCUIdx when a LCU is encoded but not included in the current slice, because it exceeds the maximum size requested (fixed slice length). This is the error: TAppEncoderStatic_HM-10.1-dev_2013_05_09: /home/joaoc/IT/PhD/HEVC/srcHEVC-mirror/build/linux/lib/TLibEncoder/../../../../source/Lib/TLibEncoder/TEncRateCtrl.h:147: TRCParameter TEncRCSeq::getLCUPara(Int, Int): Assertion `LCUIdx < m_numberOfLCU' failed." jfmcarreira HM-10.0 1028 Encoder carries over tile entry point information of previously coded dependent slices into current dependent slice header HM HM-10.0 defect closed 2013-02-28T20:29:47+01:00 2013-04-02T23:55:22+02:00 The HM-10.0 encoder carries over tile entry point information of previously coded dependent slices into current dependent slice header. The proposed patch resets the tile entry point information at the start of each dependent slice. kiranmisra HM-10.0 1030 Buffer size in HM decoder HM HM-10.0 defect closed 2013-03-05T01:14:06+01:00 2013-05-07T16:06:55+02:00 "In TDecTop.cpp, there is a line as follows. ''m_iMaxRefPicNum = pcSlice->getSPS()->getMaxDecPicBuffering(pcSlice->getTLayer())+pcSlice->getSPS()->getNumReorderPics(pcSlice->getTLayer()) + 1;'' This variable m_iMaxRefPicNum is used to compare with the size of the variable m_cListPic . Why should num. of reordered pictures be part of the calculation? Shouldn't it just be as follows? ''m_iMaxRefPicNum = pcSlice->getSPS()->getMaxDecPicBuffering(pcSlice->getTLayer()) + 1; Also, it might be helpful to rename the variable m_iMaxRefPicNum because it is not indicating the number of reference pictures." adarsh HM-10.0 1033 NAL unit type names do not match text HM HM-10.0 defect closed 2013-03-05T12:33:03+01:00 2013-03-27T00:47:17+01:00 NAL unit types have been renamed in the spec text. The software should use the same names for more clarity (once the renaming in the text has been finished). ksuehring HM-10.0 1034 Syntax element names HM HM-10.0 defect closed 2013-03-05T12:34:10+01:00 2014-07-04T09:30:47+02:00 Several syntax element names have been renamed in the text. The software should be checked for mismatches an syntax element names should be aligned whenever possible. ksuehring HM-10.0 1040 Segmentation fault when decoding consecutive IDR frames HM HM-10.0 defect ksuehring closed 2013-03-11T14:58:30+01:00 2013-04-06T00:13:15+02:00 "If an encoded stream has two consecutive IDR frames then the decoder has a segmentation fault in createNonDBFilterInfoLCU. The problem appears to be that the code at line 326 of TDecTop.cpp attempts to detect a new picture by spotting a difference in picture order count: if (m_apcSlicePilot->isNextSlice() && m_apcSlicePilot->getPOC()!=m_prevPOC && !m_bFirstSliceInSequence) However, IDR frames have the POC reset to 0 so do not have a different POC. This means that the decoder interprets the second picture as a new slice of the first frame and crashes. Perhaps it is not valid for an encoded stream to have consecutive IDR frames? " peterderivaz HM-10.0 1042 defect of function initSigLastScan in TLibCommon/TComRom.cpp HM HM-10.0 defect Falei Luo closed 2013-03-13T13:52:08+01:00 2014-01-11T19:52:04+01:00 "When I was compiling the source files with ndk-build[http://developer.android.com/tools/sdk/ndk/index.html], I found a problem of function initSigLastScan in TCommon/TComRom.cpp by keeping logs. {{{ if( iWidth > 4 ) { UInt uiNumBlkSide = iWidth >> 2; UInt uiNumBlks = uiNumBlkSide * uiNumBlkSide; // Uint log2Blk default(-1) + 1 -> 0, but it becomes 256 in my compiler. // So I suggest that log2Blk's type be fixed as Char. // My Android app broke down because of this. Char log2Blk = g_aucConvertToBit[ uiNumBlkSide ] + 1; }}} " luofl1992 HM-10.0 1051 Error when decoding sequences with multiple sequence parameter sets HM HM-10.0 defect closed 2013-03-25T17:32:04+01:00 2013-03-26T19:34:40+01:00 "In TDecCavlc::parseSPS there is code to set the global variable ```g_uiMaxCUDepth``` at the line: ```g_uiMaxCUDepth = uiMaxCUDepthCorrect+g_uiAddCUDepth;``` However, if a bitstream contains multiple sequence parameter sets with different values for ```log2_diff_max_min_coding_block_size``` the value for the global variable may be incorrect. This results in the error: ```Assertion `uiLog2TrafoSize > pcCU->getQuadtreeTULog2MinSizeInCU(uiAbsPartIdx)' failed.``` Perhaps the global variables need to be changed when the active SPS is changed?" peterderivaz HM-10.0 1052 checkCRA function with long-term reference pictures HM HM-10.0 defect closed 2013-03-26T01:44:32+01:00 2013-04-01T03:45:22+02:00 The checkCRA function used at the decoder (TDecTop.cpp) most likely not work when LTRPs are present after a CRA picture and only the LSB of the LTRP is signaled, because the LSB of the LTRP is compared with the pocCRA variable inside the checkCRA function. The attached patch is one solution to fix the problem, by fetching the actual POC of the LTRP inside the checkCRA function. Please note that the patch needs to be added on top of the patch submitted as part of Ticket 599 (due to changes in xGetLongTermRefPic function). adarsh HM-10.0 1053 max_dec_pic_buffering signalling in VPS and SPS HM HM-10.0 defect closed 2013-03-26T01:56:43+01:00 2013-04-02T23:30:32+02:00 VPS/SPS max_dec_pic_buffering should be signalled with minus1 values, i.e., vps_max_dec_pic_buffering_minus1[i] and sps_max_dec_pic_buffering_minus1[i]. mcoban HM-10.0 1056 heap corruption when decoding bitstream with HRD parameters HM HM-10.0 defect closed 2013-03-30T15:45:55+01:00 2013-04-01T01:40:42+02:00 "Caused by incorrect delete: {{{ diff --git a/source/Lib/TLibCommon/TComSlice.cpp b/source/Lib/TLibCommon/TComSli index f7ca310..8728aa0 100644 --- a/source/Lib/TLibCommon/TComSlice.cpp +++ b/source/Lib/TLibCommon/TComSlice.cpp @@ -1203,9 +1203,9 @@ TComVPS::TComVPS() TComVPS::~TComVPS() { - if( m_hrdParameters != NULL ) delete m_hrdParameters; - if( m_hrdOpSetIdx != NULL ) delete m_hrdOpSetIdx; - if( m_cprmsPresentFlag != NULL ) delete m_cprmsPresentFlag; + if( m_hrdParameters != NULL ) delete[] m_hrdParameters; + if( m_hrdOpSetIdx != NULL ) delete[] m_hrdOpSetIdx; + if( m_cprmsPresentFlag != NULL ) delete[] m_cprmsPresentFlag; } // ---------------------------------------------------------------------------- }}} " stefane HM-10.0 1059 bitstream random access issue HM HM-10.0 defect closed 2013-04-02T01:52:36+02:00 2013-04-02T23:41:49+02:00 "HM decoder assert failes when skipping frames to randomly access bitstream (encoder_randomaccess_main.cfg). Fix is proposed in attached patch. TAppDecoder.exe -b test.bin -o dec.yuv -s 13 HM software: Decoder Version [10.0][Windows][VS 1600][32 bit] Warning: this is not a valid random access point and the data is discarded until the first CRA picture POC 32 TId: 0 ( I-SLICE, QP 32 ) [DT 0.016] [L0 ] [L1 ] [] Assertion failed: rpcPic->getSlice( 0 )->isReferenced()==0||rpcPic->getUsedByCurr()==0||r pcPic->getSlice( 0 )->getTemporalLayerNonReferenceFlag()==false, file ..\..\sour ce\Lib\TLibCommon\TComSlice.cpp, line 896 " geertv HM-10.0 1060 Segmentation fault when decoding streams with multiple picture parameter sets HM HM-10.0 defect ksuehring closed 2013-04-02T13:06:07+02:00 2013-04-08T11:51:55+02:00 "If a stream uses a PPS that is not the most recent, then we can get a segmentation fault in the reference decoder. This applies to both the version tagged 10.0, and the current development branch (as of 2 April 2013). {{{ Program received signal SIGSEGV, Segmentation fault. __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1524 in ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S #1 0x0000000000430135 in TDecSbac::xCopyContextsFrom (this=0xa776c8, pSrc=0xa17e48) at /apollo/pfcd/work/hevc/HM-10.0dev/build/linux/lib/TLibDecoder/../../../../source/Lib/TLibDecoder/TDecSbac.cpp:1532 }}} The reason appears to be that the size of the context memory is set in TDecTop::xDecodePPS via line 604 of TDecTop.cpp to be {{{ Int NumCtx = pps->getEntropyCodingSyncEnabledFlag()?2:1; }}} This code is activated when a PPS is decoded. The problem occurs if we have a PPS with EntropyCodingSyncEnabledFlag==1, followed by another with EntropyCodingSyncEnabledFlag==0, followed by a CVS that uses the first PPS. This ends up trying to use m_cSliceDecoder.CTXMem[1] which is now pointing to deallocated memory. Note that the specification includes the constraint {{{ It is a requirement of bitstream conformance that the value of entropy_coding_sync_enabled_flag shall be the same for all PPSs that are activated within a CVS. }}} However, this does not appear to prohibit this case as only a single PPS is activated within the CVS. Perhaps a workaround would be to always set NumCtx equal to 2?" peterderivaz HM-10.0 1061 HM decoder crashes when field_seq_flag is equal to 1 HM HM-10.0 defect closed 2013-04-03T01:01:55+02:00 2013-04-03T18:35:49+02:00 "The HM decoder crashes when field_seq_flag is equal to 1 due to the following code line in file TDecCAVLC.cpp assert(pcVUI->getFieldSeqFlag() == false); After removing the above code, the decoder works fine by outputing field pictures sequentially. Michael" zhyang123 HM-10.0 1062 HM decoder crashes when there is no payload_bit_equal_to_zero at the end of a SEI message HM HM-10.0 defect closed 2013-04-03T03:39:10+02:00 2013-04-03T18:29:42+02:00 "HM decoder crashes when there is no payload_bit_equal_to_zero at the end of a SEI message. Specifically, the following code READ_CODE (payloadBitsRemaining-1, dummy, ""payload_bit_equal_to_zero""); will trigger an assert failure when payloadBitsRemaining is equal to 1 assert ( uiLength > 0 ); A patch is attached to fix this issue. Best regards, Michael" zhyang123 HM-10.0 1063 Random access with IDR issue HM HM-10.0 defect closed 2013-04-03T18:18:18+02:00 2013-04-04T12:46:00+02:00 "For following test condition: encoder_randomaccess_main.cfg + DecodingRefreshType = 2 (IDR) The IDRs are of type IDR_W_RADL and the problem is that the leading pictures are labeled as trailing pictures." geertv HM-10.0 1064 TComPrediction may allocate undersized temp buffer HM HM-10.0 defect ksuehring closed 2013-04-03T20:48:40+02:00 2013-04-06T00:52:27+02:00 "In TComPrediction.cpp::initTempBuff(), the temp array is created with the global variables indicating max CU size. However if an new SPS comes in the sequence that specifies a larger max CU size, the buffer is not re-created and memory outside the arrays can be accessed. The attached patch fixes the issue by allocating the maximum possible size, regardless of globals." pieterkapsenberg HM-10.0 1065 Accessing unallocated memory when looking at colocated CUs HM HM-10.0 defect karlsharman closed 2013-04-04T23:40:17+02:00 2015-03-24T10:33:16+01:00 "It appears that for an IDR (or I slice maybe?) picture, HM destroys or otherwise changes the m_pePredMode array, causing intra checks to fail. This shows up in TComDataCU::xGetColMVP, line 3292, where a colocated CU's intra mode is checked, and the colocated CU belongs to an IDR picture. A crude fix is to make sure the colocated CU's slice is not intra. A patch that does this is attached" pieterkapsenberg HM-10.0 1068 Slice RPS parsing can modify RPS in SPS HM HM-10.0 defect closed 2013-04-09T01:05:53+02:00 2013-04-09T01:19:27+02:00 "When a slice references an RPS from the SPS, and also has long term pictures, the RPS (held by SPS) is modified to include the long term pictures. Then when a later picture has a slice that parses its own RPS, and uses that SPS-held RPS as the predictor, the parsing process is incorrect because the for loop in parseShortTermRefPicSet() also goes over the long term references, which it should not do. I believe the attached patch should fix the issue." pieterkapsenberg HM-10.0 1069 HM omits dependent slices when skipping RASL pics HM HM-10.0 defect closed 2013-04-10T02:36:48+02:00 2013-04-10T14:03:56+02:00 In TDecTop::xDecodeSlice, where the decode decides if it needs to skip leading pictures of CRA or BLA pictures, the check is never performed for dependent slices, causing a decode of a rogue dependent slice. The attached patch should fix the issue. pieterkapsenberg HM-10.0 1072 numDU = 0 causes divide by zero, run time error HM HM-10.0 defect closed 2013-04-11T22:10:17+02:00 2013-05-07T18:13:07+02:00 "In TEncGOP::compressGOP(...) numDU is initialized to zero for SliceMode != 1: UInt numDU = ( m_pcCfg->getSliceMode() == 1 ) ? ( pcPic->getNumCUsInFrame() / maxCU ) : ( 0 ); this leads to a divide by zero when SliceMode == 0 in the following call: pcSlice->getSPS()->setHrdParameters( m_pcCfg->getFrameRate(), numDU, m_pcCfg->getTargetBitrate(), ( m_pcCfg->getIntraPeriod() > 0 ) ); ... ducpbSizeValue = bitRate/numDU; Not sure how to best prevent this - greg" gregcoppa HM-10.0 1073 for testing HM HM-10.0 defect closed 2013-04-13T12:05:18+02:00 2013-04-17T14:18:14+02:00 sjb100kimo HM-10.0 1076 Encoder generates a non-conforming bitstream by encoding a coefficient level of +32768 when sign hiding is enabled HM HM-10.0 defect closed 2013-04-20T01:37:37+02:00 2013-04-20T04:59:06+02:00 "I encountered a case where the encoder generated a bitstream containing a +32768 coefficient level when sign hiding is enabled. After some debugging, the code responsible is located inside the function xRateDistOptQuant() of TComTrQuant.cpp. Relevant code (lines 1988-2000): {{{ if(piQCoef[minPos] == 32767 || piQCoef[minPos] == -32768) { finalChange = -1; } if(plSrcCoeff[minPos]>=0) { piDstCoeff[minPos] += finalChange ; } else { piDstCoeff[minPos] -= finalChange ; } }}} Adding a printf after the first 'if' block: printf(""xRateDistOptQuant: minPos=%d plSrcCoeff[minPos]=%d piQCoef[minPos]=%d piDstCoeff[minPos]=%d finalChange=%d\n"", minPos, plSrcCoeff[minPos], piQCoef[minPos], piDstCoeff[minPos], finalChange); I got the following output (for a DC coefficient): xRateDistOptQuant: minPos=0 plSrcCoeff[minPos]=20059 piQCoef[minPos]=124277 piDstCoeff[minPos]=32767 finalChange=1 As a result, the second 'if' adjusted the coefficient level to +32768 which got placed into the bitstream. Two possible solutions: 1. Add saturation to [-32768, +32767] for piDstCoeff[minPos] after the second 'if' block. 2. It's very likely that the first 'if' is wrong and piDstCoeff should be checked instead of piQCoef. A similar piece of code can be found in lines 969-981 of the same file. " livium HM-10.0 1078 max_latency_increase signalling in VPS and SPS HM HM-10.0 defect closed 2013-04-25T10:24:25+02:00 2013-05-07T18:08:40+02:00 VPS/SPS max_latency_increase[i] should be signalled with plus1 values. tajime HM-10.0 1079 cpb_size_du_value_minus1 signalling HM HM-10.0 defect closed 2013-04-25T10:26:22+02:00 2013-05-07T17:58:57+02:00 cpb_size_du_value_minus1[i] should be signalled before bit_rate_du_value_minus1[i]. tajime HM-10.0 1085 Insufficient bits for the result of luma quarter pel interpolation in HM code. HM HM-10.0 defect closed 2013-05-03T13:22:54+02:00 2013-05-07T16:02:25+02:00 " The data type of the interpolated pixels in Short *dst is insufficient for a implementation of the filter conforming to JCTVC-L1003_v34 'short' can be 16 bits depending upon the platform and compiler used. template Void TComInterpolationFilter::filter(Int bitDepth, Short const *src, Int srcStride, Short *dst, Int dstStride, Int width, Int height, Short const *coeff) Examples of case when 16 bits is insufficient is the quarter-sample location 'j' (8-209). The maximum and minimum interpolated values of quarter-sample location 'j' depends on the range of 'b' (8-200). Assume eight bit input. In equation (8-200) The maximum of 'b' occurs when A(−3,0) = 0, A(−2,0) = 255, A(−1,0) = 0, A(0,0) = 255, A(1,0) = 255, A(2,0) =0, A(3,0) = 255, A(4,0) = 0. The maximum of 'b' is 88*255. The minimum of 'b' occurs when A(−3,0) = 255, A(−2,0) = 0, A(−1,0) = 255, A(0,0) = 0, A(1,0) = 0, A(2,0) =255, A(3,0) = 0, A(4,0) = 255. The minimum of 'b' is -24*255. For quarter-sample location 'j', in equation (8-209) The maximum of 'j' occurs when b(0,-3) = -24*255, b(0,−2) = 88*255, b(0,−1) = -24*255, b(0,0) = 88*255, b(0,1) = 88*255, b(0,2) = -24*255, b(0,3) = 88*255, b(0,4) = -24*255. The maximum of 'j' is 33150 The minimum of 'j' occurs when b(0,-3) = 88*255, b(0,−2) = -24*255, b(0,−1) = 88*255, b(0,0) = -24*255, b(0,1) = -24*255, b(0,2) = 88*255, b(0,3) = -24*255, b(0,4) = 88*255. The minimum value is -16830. The maximum of 'j' is greater than 32767(the maximum that can be represented by 16 bits). The current implementation of the filter does not confrom to the JCTVC-L1003_v34 draft of the standard when bi-prediction is used. " ManojJames HM-10.0 1087 Buffer allocation for substream with wpp HM HM-10.0 defect closed 2013-05-07T16:39:31+02:00 2013-05-07T17:44:52+02:00 "Hi, I've got an error with this stream on HM10.0 . Disclaimer: This stream has been made by me so it can't be considered as bugfree. However, it looks like HM encounters an assert on this stream at the end of first wavefront. This assert is a check on fifo size to ensure hm still have an allocated buffer wile reading on it. It looks like the buffer size just has 1 byte missing (264 rather than 265). What do you think of this ? Do you confirm me it is an HM bug ? Thanks and Regards," lagorsse HM-10.0 1093 bug fix for rate control HM HM-10.0 defect closed 2013-05-14T10:58:56+02:00 2013-05-15T13:31:17+02:00 "Thanks Wang, Xianglin (Shawn) for fixing a bug in r3493. The bug was introduced by M0036_RC_IMPROVEMENT. But with that bug fix, the LCU level target bits are not set properly when getUseLCUSeparateModel() is false. I think the attached patch is a better way to fix that bug." libin HM-10.0 1094 Incorrect decode at bitdepth 14 HM HM-10.0 defect closed 2013-05-21T16:18:25+02:00 2013-05-23T20:38:55+02:00 "Does the HM software support bitdepths above 10? Main and Main10 profile only use bitdepths 8,9, or 10 so perhaps high bitdepths are not supported? However, the HEVC text allows bitdepths 8,9,10,11,12,13, or 14. The HM software appears to decode incorrectly at high bitdepths. For example, in the function TComTrQuant::xITransformSkip there is the line: pResidual[j * uiStride + k] = plCoef[j*width+k] << transformSkipShift; Suppose transformSkipShift = 1. pResidual is a 16bit number, so shifting plCoef can result in integer overflow. (Also this scaling will mean that the residual is always an even number.) " peterderivaz HM-10.0 1096 Reference decoder treats IRAP pictures as trailing pictures, as regards RPS rules HM HM-10.0 defect new 2013-05-24T17:48:51+02:00 2014-04-10T12:30:28+02:00 "I have a stream with a CRA NAL that references a RADL picture from the preceding IRAP. The stream looks like this: IDR picture (POC=0) RADL picture (POC=-4) (other leading and trailing pictures) CRA picture (POC=25) The CRA picture references the RADL picture with a POC of -4. Using the reference decoder, this asserts on line 621 of TComSlice.cpp, in this loop in checkCRA(): {{{ for(Int i = 0; i < pReferencePictureSet->getNumberOfNegativePictures()+pReferencePictureSet->getNumberOfPositivePictures(); i++) { if(pocCRA < MAX_UINT && getPOC() > pocCRA) { assert(getPOC()+pReferencePictureSet->getDeltaPOC(i) >= pocCRA); } } }}} This loop is quite correct as regards trailing pictures, but should the same rules apply to CRA pictures? It looks to me from the spec as though CRA pictures should be able to reference pictures that came before the preceding IRAP in output order (although not in decoding order). Spec section 8.3.2: - When the current picture is a CRA picture, there shall be no picture included in the RPS that precedes, in decoding order, any preceding IRAP picture in decoding order (when present). and - When the current picture is a trailing picture, there shall be no picture in the RPS that precedes the associated IRAP picture in output order or decoding order. So it looks like the reference decoder is incorrectly treating IRAP pictures the same as trailing pictures, unless I'm missing something in the spec. This problem could be solved by moving the two for loops at the top of checkCRA() below the if statements currently at the bottom, so that pocCRA would be updated before running the checks. " jackh HM-10.0 1097 Incorrect long term reference POC calculation in reference decoder HM HM-10.0 defect closed 2013-05-28T18:11:17+02:00 2013-06-04T16:47:15+02:00 "I think the reference decoder has an incorrect calculation for long term reference picture POCs in the case where delta_poc_msb_present_flag is equal to zero and the current POC's MSB is non-zero. The incorrect code can be found in TDecCAVLC.cpp, lines 1005 and 1006: {{{ rps->setPOC (j, pocLsbLt); rps->setDeltaPOC(j, - rpcSlice->getPOC() + pocLsbLt); }}} The spec states that when delta_poc_msb_cycle_lt is not present (i.e. delta_poc_msb_present_flag is equal to zero), it is inferred to be zero. The section of code above the incorrect section (which calculates long term reference POCs for the case when delta_poc_msb_present_flag==1) is correct, and says: {{{ Int pocLTCurr = rpcSlice->getPOC() - deltaPocMSBCycleLT * maxPicOrderCntLSB - iPOClsb + pocLsbLt; rps->setPOC (j, pocLTCurr); rps->setDeltaPOC(j, - rpcSlice->getPOC() + pocLTCurr); }}} Setting delta_poc_msb_present_flag==0 should have the effect of making deltaPocMSBCycleLT be assumed to be zero, i.e. the correct code at lines 1005 and 1006 would be: {{{ Int pocLTCurr = rpcSlice->getPOC() - iPOClsb + pocLsbLt; rps->setPOC (j, pocLTCurr); rps->setDeltaPOC(j, - rpcSlice->getPOC() + pocLTCurr); }}} exactly as above, but with deltaPocMSBCycleLT=0. Substituting this for the current code gives the correct behaviour." jackh HM-10.0 1099 Repeating the active SPS leaves a dangling pointer in previously decoded pictures HM HM-10.0 defect closed 2013-05-29T13:43:52+02:00 2014-10-14T16:26:01+02:00 "I have a stream which has an SPS_NUT NAL in the middle of a CVS which repeats the active SPS. I think this is legal by the spec; section 7.4.2.4.2 says: Any SPS NAL unit containing the value of sps_seq_parameter_set_id for the active SPS RBSP for a CVS shall have the same content as that of the active SPS RBSP for the CVS, unless it follows the last access unit of the CVS and precedes the first VCL NAL unit and the first SEI NAL unit containing an active parameter sets SEI message (when present) of another CVS. When the reference decoder is parsing this stream, it calls ParameterSetManagerDecoder::storePrefetchedSPS() (TDecSlice.cpp). This causes the previous copy of the SPS to be deleted and the newly allocated pointer to be stored. Any references held by stored slices to the previous pointer become dangling pointers, and can subsequently crash the reference picture set code. I would imagine that the same problem will be seen for PPSs and VPSs I can see several possible solutions to this problem: 1) Just store the parameter set ID in the slice rather than a pointer, and look up the parameter set in the ParameterSetManager every time it's needed, so that the new pointer will be picked up. This might be a problem for PPSs, as they could legitimately have been replaced since the slice was decoded, so the slice might end up referring to the wrong PPS. 2) Check if the parameter sets are equal to each other before storing them. If so, don't change the existing pointer. This will have the same problem as above for PPSs, and incurs processing time for checking equality of all parameters (although this would enable the decoder to detect the non-conformant case when the active SPS or VPS is being replaced by a different SPS or VPS) 3) Use std::shared_ptr to refer to parameter sets. This way they will be deleted once no further references are held to them, and slices will always hold the parameter sets they originally referred to. " jackh HM-10.0 1100 Calculation for PicWidthInCtbsY doesn't seem to match the spec HM HM-10.0 defect closed 2013-05-31T18:12:35+02:00 2013-06-04T19:30:25+02:00 "In TComSampleAdaptiveOffset::create(), there are four lines which I believe correspond to equations 7-15 and 7-17 in the spec: {{{ m_iNumCuInWidth = m_iPicWidth / m_uiMaxCUWidth; m_iNumCuInWidth += ( m_iPicWidth % m_uiMaxCUWidth ) ? 1 : 0; m_iNumCuInHeight = m_iPicHeight / m_uiMaxCUHeight; m_iNumCuInHeight += ( m_iPicHeight % m_uiMaxCUHeight ) ? 1 : 0; }}} Spec: PicWidthInCtbsY = Ceil( pic_width_in_luma_samples ÷ CtbSizeY ) (7-15) PicHeightInCtbsY = Ceil( pic_height_in_luma_samples ÷ CtbSizeY ) (7-17) In order to match the spec, should these lines not read: {{{ m_iNumCuInWidth = m_iPicWidth / m_uiMaxCUHeight; m_iNumCuInWidth += ( m_iPicWidth % m_uiMaxCUHeight ) ? 1 : 0; m_iNumCuInHeight = m_iPicHeight / m_uiMaxCUHeight; m_iNumCuInHeight += ( m_iPicHeight % m_uiMaxCUHeight ) ? 1 : 0; }}} instead? Seems like the division should be by the same quantity for both equations. " jackh HM-10.0 1101 Multiple CVSs and skipped leading pictures crash the reference decoder HM HM-10.0 defect new 2013-05-31T18:36:59+02:00 2014-04-10T12:30:28+02:00 "I have a stream with multiple CVSs in one bitstream, and also with BLA pictures in the stream with associated RASLs. This causes the reference decoder to assert in TComInputBitstream::read(), as it runs over the end of the buffer. The attached patch fixes the two problems which together cause this. An explanation of them is below. Firstly, the reference decoder doesn't recognise the beginning of a new CVS (i.e. the presence of an EOS, BLA or IDR NAL) and reset m_pocRandomAccess accordingly. The patch fixes this by setting m_pocRandomAccess back to MAX_INT (its initial state) whenever such a condition is encountered, so that isRandomAccessSkipPicture() will pick up the new random access POC when it is called. Secondly, when skipping frames, the decoder calls copySliceInfo to copy the previous slice segment's information, but as the previous slice segment was skipped, this brings in the previous POC, dropping the decoder out of skipping early. The patch fixes this with an extra flag which signals that the previous slice segment was skipped, so copySliceInfo should not be called. The flag also suppresses any hash SUFFIX_SEI NALs associated with skipped pictures from being processed, as otherwise the hash NALs of skipped frames would be taken as applying to the picture before the skipping began, causing a multiple hash SEI warning." jackh HM-10.0 1102 Deblocking offsets wrongly checked HM HM-10.0 defect closed 2013-06-03T13:51:16+02:00 2013-06-04T16:52:40+02:00 "m_loopFilterBetaOffsetDiv2 & m_loopFilterTcOffsetDiv2 are checked for value in range -13 to 13 exclusive, whereas it should be -6 to 6 inclusive. Function :- Void TAppEncCfg::xCheckParameter()" amitkchawla HM-10.0 1103 there is no intra pred ref sample check HM HM-10.0 defect David Flynn closed 2013-06-07T04:40:21+02:00 2019-04-19T00:18:38+02:00 according to 8.4.4.2.2 of JCTVC-L1003_v34,we need check the available status of ref sample before cal presamples, but this is missing on HM-10 jesanluo HM-10.0 1104 Filtering process of neighbouring samples is missing in our code HM HM-10.0 defect David Flynn closed 2013-06-07T04:46:34+02:00 2013-06-07T15:31:48+02:00 "according to 8.4.4.2.3 of JCTVC-L1003_v34,we need filter the neighbouring sample in two ways, but this is missing " jesanluo HM-10.0 1105 colPb location hadn't be correct HM HM-10.0 defect David Flynn closed 2013-06-07T05:12:53+02:00 2013-06-07T15:30:29+02:00 accodding to 8.5.3.2.7 of JCTVC_L1003_V34 , the location of colPb need align with 16, but this is not corrected on HM-10 jesanluo HM-10.0 865 SEI writing inefficient HM HM-10.0 enhancement ksuehring closed 2012-11-28T14:14:10+01:00 2015-02-19T18:01:55+01:00 "Each SEI messages is written into an own NAL unit. Multiple messages can be accumulated into one NAL unit to save overhead. Adding an option to switch between single NAL units and aggregation into one would be preferable." ksuehring HM-10.0 1038 bitstream check when termination bin is 1 HM HM-10.0 enhancement closed 2013-03-06T17:12:37+01:00 2013-05-13T16:15:15+02:00 "I would like to add the following check when termination bin (end_of_slice_segment_flag, pcm_flag and end_of_sub_stream_one_bit) is 1 in the function {{{ Void TDecBinCABAC::decodeBinTrm( UInt& ruiBin ) { m_uiRange -= 2; UInt scaledRange = m_uiRange << 7; if( m_uiValue >= scaledRange ) { ruiBin = 1; assert ((m_uiValue >> 7) & 1); UInt numBits = m_pcTComBitstream->getNumBitsUntilByteAligned(); if(numBits) { assert(numBits <= m_pcTComBitstream->getNumBitsLeft()); UInt code; m_pcTComBitstream->pseudoRead( numBits, code ); assert(code == 0); } } else ... }}}" PhuongNguyen HM-10.0 1039 check alignment_bit_equal_to_one HM HM-10.0 enhancement closed 2013-03-06T18:53:47+01:00 2013-05-07T15:57:06+02:00 "When we decode end_of_sub_stream_one_bit, the result must be one and it corresponds to alignment_bit_equal_to_one. I would like to add the following check : {{{ Void TDecSbac::updateContextTables( SliceType eSliceType, Int iQp ) { UInt uiBit; m_pcTDecBinIf->decodeBinTrm(uiBit); assert(uiBit); m_pcTDecBinIf->finish(); ... }}}" PhuongNguyen HM-10.0 1050 parse end_of_sub_stream_one_bit in WPP HM HM-10.0 enhancement closed 2013-03-25T10:42:04+01:00 2013-05-07T15:52:39+02:00 "In WPP, the text requires to parse the syntax element end_of_sub_stream_one_bit at the end of each tile line if end_of_slice_segment_flag is equal to 0. It corresponds to the syntax element alignment_bit_equal_to_one and it must be equal to one. It seems that the parsing of end_of_sub_stream_one_bit and the check have not been done in the reference software in WPP. I suggest to add the following code in the function {{{ Void TDecSlice::decompressSlice(TComInputBitstream** ppcSubstreams, TComPic*& rpcPic, TDecSbac* pcSbacDecoder, TDecSbac* pcSbacDecoders) ... cSigma.m_CbCounter=0; #endif #endif m_pcCuDecoder->decompressCU ( pcCU ); #if ENC_DEC_TRACE g_bJustDoIt = g_bEncDecTraceDisable; #endif pcSbacDecoders[uiSubStrm].load(pcSbacDecoder); UInt uiTileRightEdgePosInCU = rpcPic->getPicSym()->getTComTile(rpcPic->getPicSym()->getTileIdxMap(iCUAddr))->getRightEdgePosInCU(); UInt ruiBit; if ( (uiCol == uiTileRightEdgePosInCU) && (pcSlice->getPPS()->getEntropyCodingSyncEnabledFlag()) && !uiIsLast) { pcSbacDecoder->parseTerminatingBit(ruiBit); assert (ruiBit); } //Store probabilities of second LCU in line into buffer if ( (uiCol == uiTileLCUX+1)&& (depSliceSegmentsEnabled || (pcSlice->getPPS()->getNumSubstreams() > 1)) && (pcSlice->getPPS()->getEntropyCodingSyncEnabledFlag()) ) { m_pcBufferSbacDecoders[uiTileCol].loadContexts( &pcSbacDecoders[uiSubStrm] ); } ... }}}" PhuongNguyen 36 Encoder-crash when no 8x8 CU case with RQT=1 HM defect fbossen closed 2010-08-11T04:54:29+02:00 2010-08-17T10:08:00+02:00 "If we configure the framework structure not having 8x8 CU with RQT=1, the encoder seems to be crashed. For example, -s 16 -h 2 (ok) -s 16 -h 1 (crash) -s 32 -h 3 (ok) -s 32 -h 2 (crash) -s 64 -h 4 (ok) -s 64 -h 3 (crash) Turning off RQT seems to be ok." wjhan 49 TMuC0.7 crashes when QuadtreeTULog2MinSize = 3 HM defect closed 2010-08-16T21:19:26+02:00 2010-08-17T19:37:37+02:00 the encoder crahes for all the configurations when 4x4 transform is disabled. zhou@… 50 Encoder crash when CUsize as 32 HM defect fbossen closed 2010-08-17T01:06:56+02:00 2010-08-31T19:54:33+02:00 As part of TE12, we are testing CUSize=32, MaxPartitionDepth =3. However, the encoder crashes at frame no. 218 for BasketballDrive 1080p at low delay high efficiency case. yyu@… 55 TMuC 0.7 encoder hangs up (does not crash) on specific conditions HM defect closed 2010-08-18T08:13:38+02:00 2010-09-08T15:46:49+02:00 "TMuC 0.7 encoder hanged up when using encoder_randomaccess.cfg (random-access, high efficiency). The encoding process seems to fall in an infinite loop. We have found that the problem occurs on the following two conditions. 1) Tennis, Qp=37 (This sequence may be needed for TE10) 2) Cactus, Qp=27 At least as for (1), this problem happened on a 64-bit Windows 7 Professional platform (CPU: Core i7 930 2.8GHz, Memory: 12GB), but did not happen on a 64-bit Windows XP Professional platform (CPU: Core i7 960 3.2GHz, Memory: 12GB). For both platforms, the encoder executable is 64-bit version build with Visual C++ 2008. Is this related to v0.7.1 fixes? Or is this a new defect?" hao@… 80 Decoder crash when using (modified) encoder_lowdelay.cfg HM defect closed 2010-08-27T10:30:34+02:00 2011-03-21T12:03:43+01:00 "When using encoder_lowdelay.cfg with parameter ""GOPSize"" set to 4 and parameter ""RateGOPSize"" set to 4, the decoder crashes at POC 5: Assertion failed: 0, file ..\..\source\Lib\TLibCommon\TComBitStream.cpp, line 153 The sequence-specific config file used was per-sequence/BlowingBubbles.cfg with parameter ""FrameToBeEncoded"" set to 10. " Heiner Kirchhoffer 180 HM-3.1 bug: Previous QP is not correct HM defect closed 2011-05-31T06:35:22+02:00 2011-07-05T20:10:09+02:00 "According to the decision at the Geneva meeting, new QP predictor for WD3 is introduced into HM-3.1, with the macro SUB_LCU_DQP. The predictor is defined as follows. 1. Use left negihbor (of upper-left corner of currentCU) if available 2. Otherwise, use previous in scan order. However, the current implementation fails to correctly get previous QP in scan order. TComDataCU::m_hLastCodedQP representing the previous QP is not set to the real previous QP but set to the reference QP when encoding/decoding the current QP. As a result, correct predicted QP cannot be obtained at the first CU in the left-most LCU. I believe the correct procedure is that TComDataCU::m_hLastCodedQP is set to the current QP when finishing encoding/decoding process of CU's whose depth is equal to or less than MaxCuDQPDepth. In addition, QP of CU's coded as PCM is not correctly set." hao 1 GOP size issues HM defect closed 2010-06-08T16:46:35+02:00 2010-07-23T16:14:23+02:00 When the GOP size is 12 instead of 8, the encoder and decoder do not crash, but have mismatches for frames: 1, 13, 25, 37, which are just the first frame of a GOP in display order. anonymous 7 Early skip decision is not working HM defect wjhan closed 2010-06-22T03:46:37+02:00 2010-07-28T09:28:03+02:00 "In the rev. 18, early skip decision, which is turned on with '-1 FEN' option, is not working. It slows down the encoder significantly in inter-slices. It basically due to the omission of skip-mode when MRG is turned on, however, even when MRG is turned off, early skip decision is not working due to small bug in the code introduced in rev. 18. Attached patch enables early skip decision when MRG is turned off." wjhan 13 Memory leakage in TMuC software? HM defect closed 2010-06-30T11:18:53+02:00 2010-07-07T12:55:23+02:00 "I am observing that when encoding the longer 1080p sequences (Cactus, BasketballDrill, BQTerrace) on Windows, the encoder crashes at exactly the same frame number (=496), independent of QP value and sequence. This seems to coincide with the commit charge reaching about 2GB. Is this to be expected? (2GB sounds like a huge number given the frame size.) The issue is present in revision 17, but not in the initial stripped A124 software (revision 3 I believe). The decoder seems to have similar problems, even for some class C sequences. The commit charge quickly increases to 2 GB after encoding a few frames. Details: - I am using the Beta script with unmodified configuration files and fast encoder settings (cft-fast). - The problem is present on Windows XP/32-bit OS and on Windows 7/64 bit OS when compiling with “32-bit settings”. - Compiling with “64 bit settings” and/or enabling large addresses when linking and running on 64-bit Windows OS seems to fix the problem for both the encoder and decoder (although the decoder slows down significantly when exceeding 4 GB working its way up to 18 GB commit charge  ). " arild.fuldseth@… 14 Memory leak in the decoder HM defect closed 2010-07-08T14:40:28+02:00 2010-07-23T16:17:17+02:00 "Serious memory leak was observed in the decoder. Decoding about 80 1920x1080 frames will consume 2 GB memory! The memory leak mainly occurs in Void TComDataCU::destroy(). When the lib is marked as decoder, the memory in the following blocks will be never freed. if ( !m_bDecSubCu ) { xFree .... } " li@… 26 Bug fixes for IMVP HM defect fbossen closed 2010-08-09T13:16:00+02:00 2010-08-10T19:23:40+02:00 "In TMuC0.5 In TComDataCU.cpp, function : insertCollocated, line 2703 The original purpose of the above is to avoid multiple insertion. However, from the above code, the cMv is always inserted. The fix uses instead of. function : clearMVPCand, lines 3311, 3332 and function : clearMVPCand_one_fourth, line 3171 The test to reduce the list of AMVP is false, when HHI_IMVP is turned on. The test should be done only for the vertical component when HHI_IMVP is turned on. function : clearMVPCand, lines 3290, 3292, 3369 The test to reduce the list of AMVP should be done only for the vertical component when HHI_IMVP is turned on (following the last fix). In consequence, before processing this reduction, the vertical components of the AMVP list which are redundant should be erased, when HHI_IMVP is turned on. This fix works like the function xUniqueMVPCand_one_fourth, line 3072. In TDecEntropy.cpp, In function decodeMVPIdx, lines 1010, 1013, 1082, 1085, 1154, 1157, 1124, 1227, 1295, 1298, 1365, 1369, 1502, 1505 Remplacement of iPartIdx by uiPartAddr for the functions : clearMVPCand_one_fourth and clearMVPCand This parameter is used in these functions for the test: !pcCU->isSkip(uiPartAddr) when HHI_IMVP is turned on. This bug allowed IMVP for SKIP/DIRECT, that isn't correct. In function decodeMVPIdx, lines 1036, 1046, 1108, 1118, 1179, 1189, 1259, 1267, 1320, 1330, 1391, 1401, 1528, 1538 Remplacement of iPartIdx by uiPartAddr for the same test: !pcSubCU->isSkip(uiPartAddr) In TEncSearch.cpp, In function predInterSearch, lines 3809, 3824, 3839, 3854, 3890, 3905, 3938, 3953 Remplacement of iPartIdx by uiPartAddr for the functions : clearMVPCand_one_fourth and clearMVPCand This parameter is used in these functions for the test: !pcCU->isSkip(uiPartAddr) when HHI_IMVP is turned on. This bug allowed IMVP for SKIP/DIRECT, that isn't correct. All these fixes are accessible with the flag HHI_IMVP_HHI in the branche TMuC_hhi-0.5." simon.oudin@… 32 SIFO and MOMS filter incompatibilities (DPB memory) HM defect closed 2010-08-10T17:53:41+02:00 2010-10-20T04:46:32+02:00 "The SIFO FIR filters are operating on different reference frames than the MOMS FIR filters. This is a problem when adding MOMS to the SIFO filter set. getPicYuvRec() vs. getPicYuvRecFilt()" benjamin.bross@… 46 Low complexity entropy coder (LCEC) is broken for HHI_TRANSFORM_CODING=0 HM defect fbossen closed 2010-08-16T09:07:48+02:00 2010-08-17T10:09:10+02:00 "Corrupt bitstream and encoder/decoder mismatch for SymbolMode=0 and #define HHI_TRANSFORM_CODING 0 I expect a fix within a day or so. " arilfuld@… 48 bug found in TEncSearch.cpp inside SIFO motion search for different offsets HM defect fbossen closed 2010-08-16T20:45:12+02:00 2010-08-31T19:57:35+02:00 "Inside the loop of ME for different offsets for(UInt MEloop = 0; MEloop < NumMEOffsets; MEloop++) { change xPatternSearch_Bi ( pcPatternKey, piRefY, iRefStride, &cMvSrchRngLT, &cMvSrchRngRB, rcMv, ruiCost, pRefBufY, pcCU->getSlice()->isRounding() ); to xPatternSearch_Bi ( pcPatternKey, piRefY, iRefStride, &cMvSrchRngLT, &cMvSrchRngRB, cMv_temp, uiCostTemp, pRefBufY, pcCU->getSlice()->isRounding() ); " rpanchal@… 56 SIFO possible bug HM defect closed 2010-08-18T10:54:01+02:00 2010-10-20T04:55:00+02:00 Valgrind trace for ticket #50 test conditions reports conditional move or jump in TEncSIFO.cpp n.shlyakhov@… 58 Encoder crash for TE-9 S0-8 HM defect closed 2010-08-19T06:54:32+02:00 2010-10-20T04:52:30+02:00 For TE-9 S0-8, there several encoder crashes, one of them is attached as the bat\cfg and output txt for the crash analyse anonymous 68 Different results HM defect closed 2010-08-23T08:09:22+02:00 2011-02-21T22:15:34+01:00 "It seems that TMuC0.7 and TMuC0.7.1 may yield different results with different compilers. For example, for random access high efficiency configuration, when Qp=37, the results I got(compiled with VS2008 or VS2010, in 64bits) are as follows. Bitrate: 480.2856 PSNR: 30.4399(Y) 35.0552(U) 36.6993(V) The log file is attached. While the results generated by Frank and Kenneth are as follows. Bitrate: 480.47 PSNR: 30.44 (Y) 35.05 (U) 36.69 (V)" jzxu 79 VLC bug when MDDT is turned off HM defect closed 2010-08-24T10:38:55+02:00 2010-09-08T01:36:19+02:00 "As a MDDT tester in TE12, we found the following problem: TMuC VLC encodes first 64 coefficients of transformed residual in intra (after TMuC 0.5), but '''when MDDT is turned off, interleaved coding of TMuC 0.1''' is used. Furthermore, we found that '''turning off MDDT disables RDOQ''' in intra modes. It should be changed as: (1) enabling RDOQ when MDDT=0 (2) same coding method (first 64 coefficients) for MDDT=0 and 1. It affects two tests (low-complexity configuration only) in TE12: (1) MDDT-off test (2) MDDT-off + ROT-off combination test. Patch can be applied for this without affecting all other tests in TE12." wjhan 91 Adaptive scanning and decoder speed HM defect closed 2010-09-11T23:38:21+02:00 2010-10-20T04:48:40+02:00 "While doing experiments with MaxCUSize set to 32, it appeared that this significantly slows down the decoder (by about 2.5x). Further analysis indicates that a lot of time is spent in the following functions related to adaptive scanning: updateScanOrder() and normalizeScanStats() in TComROM.cpp. When removing calls to these functions, decoding times are similar for maximum CU sizes of 32 and 64. Additionally for MaxCUSize set to 64, decoding times are roughly halved when removing calls to these functions. Adaptive scanning should thus be configurable to determine whether its benefits justify the associated increase in decoding time. " fbossen 108 One bug in xWriteUnaryMaxSymbol HM defect closed 2010-11-11T09:47:50+01:00 2010-12-21T19:41:14+01:00 "One bit or bin is wasted in xWriteUnaryMaxSymbol() when uiMaxSymbol is 0. This will happen in codeRefFrmIdx(), when iRefFrame is 1 and pcCU->getSlice()->getNumRefIdx( eRefList ) is 2. So, in my opinion, uiMaxSymbol should be first checked in xWriteUnaryMaxSymbol(). This bug happens in both CABAC and CAVLC. But under the default configuration, it will not happen in low complexity case because of the combining coding in LCEC phase2." libin 118 Mismatch/Crash when QP=0 for some sequences HM defect closed 2010-12-25T01:05:15+01:00 2011-01-25T07:28:48+01:00 "QP=0, INTRA HE, 50fr Kimono -> Encoder-Decoder Mismatch Vidyo4 -> Crash for 2nd frame It looks as if ALF is the source of this bug." tung.nguyen 120 Incompatibility with HM text: below left availability in angular intra prediction HM defect closed 2011-01-24T12:17:35+01:00 2011-01-25T07:25:50+01:00 "As shown in the presentation of JCTVC-D086, following two lines in TComPattern::initAdiPattern() (TComPattern.cpp lines 248 and 249) should be removed. if (uiCuWidth<=8) bBelowLeftFlag=false; Note that there are no similar codes in TComPattern::initAdiPatternChroma()." hao 123 Bug when LCEC_CBP_YUV_ROOT macro is disabled HM defect closed 2011-02-16T11:40:17+01:00 2011-04-15T08:40:00+02:00 "When the macros LCEC_CBP_YUV_ROOT and QC_BLK_CBP are disabled in HM2.0 there is a bug in the compilation of the solution: source\Lib\TLibEncoder\TEncCavlc.cpp(1871) : error C3861: 'codeCbf': identifier not found In fact this function is only defined for LCEC_CBP_YUV_ROOT. Best regards, Simon Oudin" SimonO 125 High-precision bi-pred averaging has undesired side effects on uni-pred HM defect closed 2011-02-21T01:55:39+01:00 2011-02-27T10:04:26+01:00 "The introduction of HIGH_ACCURACY_BI affects single-list prediction when it shouldn't (introduces an additional stage of rounding). Single-list prediction should not be affected by HIGH_ACCURACY_BI and a correction is thus required. (Initially reported by M. Zhou, TI)" fbossen 129 CAVLC merge index coding bug HM defect closed 2011-02-22T20:45:04+01:00 2011-03-20T17:48:37+01:00 The binarization of the merge index in CAVLC is broken if the number of merge candidates is equal to 4. It should be truncated unary. A Fix can be found in the two attached files under the macro HHI_MRG_LCEC_FIX. bbross 195 Uninitialized context model used in xQuadTreeDecisionFunc (SAO) HM defect closed 2011-08-05T19:16:31+02:00 2011-08-12T18:54:37+02:00 "Context model m_cAOUvlcSCModel.get( 0, 0, 0 ) is used uninitialized during estimation. This can be reproduced by setting variable m_ucState of class ContextModel to 126 in the constructor (126 can never occur otherwise) and by adding a breakpoint in function getState that triggers when m_ucState equals 126. See the attached svn diff of ContextModel.cpp." Heiner Kirchhoffer 1159 mismatch due to wrong sao availabilities HM defect closed 2013-09-04T18:48:18+02:00 2013-09-04T19:11:12+02:00 "In HM12.0-dev branch, the following define breaks the sao (decoding mismatches) #define HM_CLEANUP_SAO 1 ///< JCTVC-N0230 The SAO filtering availabilities across tiles and slices are wrongly computed in TComPicSym::deriveLoopFilterBoundaryAvailibility Attached is a patch that does the correct computation." jonharper 81 AMVRES unification with GPB HM enhancement closed 2010-08-27T20:11:52+02:00 2010-10-20T04:47:29+02:00 Adaptive motion resolution currently in TMuC was designed mainly for IPPP. The unification design for GPB will be provided. wchien 84 Adding load balancing to MultiPIPE HM enhancement Frank Bossen closed 2010-09-03T02:07:32+02:00 2010-10-20T04:42:31+02:00 "Added to MultiPIPE in TMuC 0.7.3 extra information, which makes it possible for the decoder to distribute the task of entropy decoding among several parallel CPUs, such that the computational load on each CPU would be roughly equal. The ""BalancedCPU"" option in the configuration file sets the expected number of decoding CPUs (see Dresden A120). This option has no effect for serial PIPE. The load balancing information is added by the encoder, but the decoder silently ignores it in this version." korger 87 Harmonize macros DCM_PBIC and HHI_MRG_PU HM enhancement closed 2010-09-08T22:04:15+02:00 2010-09-16T23:36:38+02:00 The two macros DCM_PBIC and HHI_MRG_PU were added in parallel and need to be harmonized with each other sandeepkanumuri 90 Configurability of rounding control for bipred HM enhancement closed 2010-09-11T22:20:24+02:00 2010-10-20T04:43:52+02:00 "The ROUNDING_CONTROL_BIPRED macro enables adaptive rounding for biprediction. In addition it also modifies the distortion computation functions. To better distinguish the effect of the distortion computation modifications and the adaptive rounding itself, a configuration file option should be added to disable the adaptive rounding part. The effect of such an option would be to control the way the rounding mode is set in TEncGOP::compressGOP. " fbossen 2 The software fails when encoding HM defect davidf closed 2010-06-09T05:31:46+02:00 2010-07-23T16:58:37+02:00 "Encoding 832x480 sequence, using the command line below, after encoding POC 38, the software will fail. -c ./cfg/RaceHorsesC.cfg -ip 32 -f 96 -g 8 -r 4 -rb0 2 -rb1 2 -s 128 -h 5 -q 32 -t 8 -ltd 0 -utd 1 -1 FEN" anonymous 3 Decoder crashes with double free when run with no arguments HM defect closed 2010-06-11T16:09:23+02:00 2010-06-11T17:00:32+02:00 "{{{ $ jctvc-a124-dec ... *** glibc detected *** /home/davidf/project/build/jctvc-a124-amd64/jctvc-a124-dec: double free or corruption (!prev): 0x000000000257c390 *** }}} " davidf 4 null ptr dereference with HHI_RQT HM defect closed 2010-06-11T16:17:24+02:00 2010-06-11T17:00:52+02:00 "Using revision r11, encoder crashes at startup. backtrace: {{{ Program received signal SIGSEGV, Segmentation fault 0x0000000000454e60 in TEncCfg::getQuadtreeTUFlag (this=0x0) at source/Lib/TLibEncoder/TEncCfg.h:237 237 Bool getQuadtreeTUFlag () const { return m_bQuadtreeTUFlag; } (gdb) up #1 0x00000000004509be in ~TEncSearch (this=0x7fffd4389078) at source/Lib/TLibEncoder/TEncSearch.cpp:98 98 if( m_pcEncCfg->getQuadtreeTUFlag() ) (gdb) print m_pcEncCfg $1 = (TEncCfg *) 0x0 }}}" davidf 5 There are errors when HHI_ALF is set as 0 in TypeDef.h HM defect closed 2010-06-18T13:53:48+02:00 2010-07-23T16:50:33+02:00 I encountered several errors when I tried to set HHI_ALF as 0 in TypeDef.h. I used VC 2008 to complie the latest TMuC. anonymous 6 macro omitted HM defect closed 2010-06-21T10:17:23+02:00 2010-07-14T14:31:07+02:00 " if( pcSlice->getSPS()->getALFSeparateQt() && cAlfParam.cu_control_flag ) { m_pcAdaptiveLoopFilter->encodeQuadTree ( &cAlfParam, m_pcEntropyCoder, uiMaxAlfCtrlDepth ); } gives an error for r18 when HHI_ALF is set to 0" nickw 8 .dsw is obsolete HM defect ksuehring closed 2010-06-22T04:45:38+02:00 2010-07-27T13:37:34+02:00 Workspace for Visual Studio 6.0 does not match the correct building rules nickw 9 Horizontal tab in cfg files cannot be properly handled HM defect davidf closed 2010-06-24T09:17:50+02:00 2010-07-28T14:15:45+02:00 "Horizontal tab in cfg files cannot be properly handled, which may result in that tools cannot be enabled/disabled by settings in cfg files. A possible solution may be the following revision in char* TAppOption::chomp( char *str ) const char cTab = 9; // the char for tab while( *str == whitespace || *str == cTab ) str++; char *end = str+strlen(str)-1; while( *end == whitespace || *end == cTab ) end--; " li@… 10 Comments in cfg files cannot be properly handled for string parameters HM defect davidf closed 2010-06-24T09:21:04+02:00 2019-09-02T14:58:59+02:00 "The comments in cfg files cannot be removed from the value strings. Normally, it doesn't matter. But for string parameters like ""InputFile"", the comment after the parameter will be treated as a part of the parameter. A possible solution may be the following revision in bool TAppOption::setValue( const char *option , char *value ) for( int i = 0 ; i < option_counter ; i++ ){ if( strcmp( options[i], option ) == 0 ){ // lines for bug fixing char * pComment = strchr( value , comment ); if( pComment != NULL ) *pComment = 0; value = chomp( value ); // lines for bug fixing values[ optionindex[i] ] = (char*) malloc((strlen(value)+1)*sizeof(char)); strcpy( values[ optionindex[i] ], value ); return true; } } " li@… 11 r19 doesn't build with PLANAR_INTRA 1 and no deblocking filter HM defect davidf closed 2010-06-24T16:18:32+02:00 2010-07-28T09:59:59+02:00 "Build fails if using: {{{ #define ANG_INTRA 0 #define PLANAR_INTRA 1 #define TENTM_DEBLOCKING_FILTER 0 #define HHI_DEBLOCKING_FILTER 0 }}} Build log: {{{ source/Lib/TLibCommon/TComLoopFilter.cpp: In member function 'Void TComLoopFilter::xDeblockCU(TComDataCU*, UInt, UInt)': source/Lib/TLibCommon/TComLoopFilter.cpp:198:64: error: 'xEdgeFilterPlanarIntra' was not declared in this scope source/Lib/TLibCommon/TComLoopFilter.cpp:211:64: error: 'xEdgeFilterPlanarIntra' was not declared in this scope }}}" davidf 12 help info does not contain -int related info HM defect davidf closed 2010-06-29T03:49:57+02:00 2010-08-09T01:30:27+02:00 "When started with missing parameters in command line, help information does not contain ""-int"" option related help." nickw 15 negative values to unsigned int HM defect davidf closed 2010-07-14T15:13:17+02:00 2011-02-27T19:36:26+01:00 "in TComRom.cpp file const UInt g_auiLumaRun8x8[29][2][64] contains -1s, which gives tons of warnings" n.shlyakhov@… 18 Minor memory leak in both encoder and decoder in TMuC 0.5 HM defect fbossen closed 2010-07-30T17:40:49+02:00 2010-08-04T01:32:48+02:00 "When QC_MDDT is defined, the following variables allocated in source\Lib\TLibCommon\TComRom.cpp are not freed in the decoder. Some of them are not freed in the encoder. UInt *scanOrder4x4[9]; UInt *scanOrder4x4X[9]; UInt *scanOrder4x4Y[9]; UInt *scanOrder8x8[9]; UInt *scanOrder8x8X[9]; UInt *scanOrder8x8Y[9]; UInt *scanStats4x4[9]; UInt *scanStats8x8[9]; UInt *scanOrder16x16[NUM_SCANS_16x16]; UInt *scanOrder16x16X[NUM_SCANS_16x16]; UInt *scanOrder16x16Y[NUM_SCANS_16x16]; UInt *scanStats16x16[NUM_SCANS_16x16]; UInt *scanOrder32x32[NUM_SCANS_32x32]; UInt *scanOrder32x32X[NUM_SCANS_32x32]; UInt *scanOrder32x32Y[NUM_SCANS_32x32]; UInt *scanStats32x32[NUM_SCANS_32x32]; UInt *scanOrder64x64[NUM_SCANS_64x64]; UInt *scanOrder64x64X[NUM_SCANS_64x64]; UInt *scanOrder64x64Y[NUM_SCANS_64x64]; UInt *scanStats64x64[NUM_SCANS_64x64]; In TMuC 0.5 encoder, some of these variables are released in Void TAppEncTop::encode(). I think we'd better release them in Void destroyROM() (TComRom.cpp). Otherwise, we have to keep duplicate code in both encoder and decoder. To fix this problem, maybe we can put the following code at the end of Void destroyROM() and remove the related code in Void TAppEncTop::encode(). #if QC_MDDT //ADAPTIVE_SCAN int ipredmode; for(ipredmode=0; ipredmode<9; ipredmode++) { delete scanOrder4x4[ipredmode]; delete scanOrder4x4X[ipredmode]; delete scanOrder4x4Y[ipredmode]; delete scanOrder8x8[ipredmode]; delete scanOrder8x8X[ipredmode]; delete scanOrder8x8Y[ipredmode]; delete scanStats4x4[ipredmode]; delete scanStats8x8[ipredmode]; } // 16x16 for (int z=0; z < NUM_SCANS_16x16; z++) { delete scanOrder16x16[z]; delete scanOrder16x16X[z]; delete scanOrder16x16Y[z]; delete scanStats16x16[z]; } // 32x32 for (int z=0; z < NUM_SCANS_32x32; z++) { delete scanOrder32x32[z]; delete scanOrder32x32X[z]; delete scanOrder32x32Y[z]; delete scanStats32x32[z]; } // 64x64 for (int z=0; z < NUM_SCANS_64x64; z++) { delete scanOrder64x64[z]; delete scanOrder64x64X[z]; delete scanOrder64x64Y[z]; delete scanStats64x64[z]; } #endif " li@… 19 Memory leak in TEncAdaptiveLoopFilter.cpp (TMuC 0.5, revision 81) HM defect closed 2010-08-04T10:39:05+02:00 2010-08-09T01:31:46+02:00 "Memory leaks are observed in Void TEncAdaptiveLoopFilter::startALFEnc( TComPic* pcPic, TEncEntropy* pcEntropyCoder ) (HHI_ALF off) Member variables m_pcPicYuvTmp, m_pcBestAlfParam, m_pcTempAlfParam, ALFp, tempALFp are allocated in this function at frame level. But they are never released. The problem becomes serious when many frames are coded. A patch of bug fix is attached." li@… 20 Turning off QC_MDDT macro makes compile error (rev 67) HM defect closed 2010-08-04T10:59:40+02:00 2010-08-04T12:00:54+02:00 "Turning off QC_MDDT macro makes compile-time error like: 1>..\..\source\Lib\TLibCommon\TComTrQuant.cpp(4672) : error C2065: 'uiMode' : undeclared identifier 1>..\..\source\Lib\TLibCommon\TComTrQuant.cpp(4672) : error C3861: 'getUseMDDT': identifier not found 1>..\..\source\Lib\TLibCommon\TComTrQuant.cpp(4780) : error C2065: 'uiMode' : undeclared identifier 1>..\..\source\Lib\TLibCommon\TComTrQuant.cpp(4780) : error C3861: 'getUseMDDT': identifier not found It seems to be related to the NEWVLC macro which uses some functions defined only when QC_MDDT is equal to 1." hurumi@… 21 Frequent memory allocation (TMuC 0.5, revision 81) HM defect fbossen closed 2010-08-04T12:00:16+02:00 2010-08-19T19:31:39+02:00 "During tracing memory leak, we noticed a problem with the current ALF, CABAC and PIPE. When using encoder_lowdelay_loco.cfg code 3 WQGVA frames (gop size=2, 1 intra frame), 4452 times of memory allocation were recorded. When using encoder_lowdelay_loco.cfg and --ALF=1, memory allocation is increased to 327,753 times. When using encoder_lowdely_loco.cfg and --SymbolMode=1 (CABAC), memory allocation is increased to 12,396,839 times. When using encoder_lowdely_loco.cfg and --SymbolMode=2 (PIPE), memory allocation is increased to 12,396,839 times. (I was some surprised that we got the exact same number for CABAC and PIPE.) In principle, too frequent memory allocation will slow down the coding speed and lead to memory fragmentation. We think it is better to improve the related code." li@… 22 Boolean SymbolMode variable in TComTrQuant.h HM defect closed 2010-08-06T04:57:09+02:00 2010-08-08T13:01:10+02:00 "TComTrQuant.h: #if NEWVLC Bool m_iSymbolMode; #endif seems to be: #if NEWVLC Int m_iSymbolMode; #endif To prevent potential bug." anonymous 23 SIFO and directional filter incompatibilities HM defect closed 2010-08-07T09:23:07+02:00 2010-10-20T05:01:01+02:00 "Minor software issues related to SIFO: i) For B pictures directional filter is not checked properly. ii) Filter coefficients for directional is not switched as in separable filter." Kemal Ugur 24 meaning of --InterpFilterType=3 or 4 is not constant HM defect davidf closed 2010-08-08T15:40:12+02:00 2010-08-09T01:32:39+02:00 "If HHI_INTERP_FILTER==1, TEN_DIRECTIONAL_INTERP==1, then --InterpFilterType=3 is IPF_TEN_DIF If HHI_INTERP_FILTER==1, TEN_DIRECTIONAL_INTERP==0, then --InterpFilterType=3 is undefined If HHI_INTERP_FILTER==1, TEN_DIRECTIONAL_INTERP==0, defined QC_SIFO then --InterpFilterType=3 is IPF_QC_SIFO If HHI_INTERP_FILTER==1, TEN_DIRECTIONAL_INTERP==1, defined QC_SIFO then --InterpFilterType=4 is IPF_QC_SIFO The attached patch fixes this issue." davidf 25 broken Eclipse project HM defect ksuehring closed 2010-08-09T10:17:59+02:00 2011-03-20T16:53:39+01:00 It looks like the Eclipse project is broken and needs to be fixed. In case that the current version actually works, could please some notes be added on how to use it to a ReadMe file? martam 27 ROT index coding bug when ROT = 1 and MDDT = 0 HM defect fbossen closed 2010-08-09T14:09:01+02:00 2010-08-10T03:20:14+02:00 "ROT index is now coded even when ROT=0 and MDDT=1. For example: (when MDDT=1) if (uiWidth >= 16) encodeROTindex( pcCU, uiAbsPartIdx, uiDepth ); Should be: if ( '''pcCU->getSlice()->getSPS()->getUseROT() &&''' uiWidth >= 16 ) { m_pcEntropyCoder->encodeROTindex( pcCU, uiAbsPartIdx, uiDepth ); } " wjhan 28 Incompatibility, HHI_TRANSFORM_CODING=0, ROT=0 HM defect fbossen closed 2010-08-09T14:11:26+02:00 2010-08-10T07:57:34+02:00 "It seems large loss when HHI_TRANSFORM_CODING=0, ROT=0. Maybe due to the wrong quantization scaling matrix for this case. " wjhan 29 Encoder-decoder mismatch when CIP=0 and ROT=0 HM defect fbossen closed 2010-08-10T03:43:48+02:00 2010-08-11T09:01:58+02:00 "When CIP=0 and ROT=0, encoder-decoder mismatch exists. It seems that CIP search is performed even CIP=0 and ROT=0." wjhan 30 Compilation error when HHI_TRANSFORM_CODING=0 HM defect fbossen closed 2010-08-10T04:26:47+02:00 2010-08-10T07:57:03+02:00 Compilation error due to the conflict between HHI_TRANSFORM_CODING macro and NEWVLC macro. It can be easily fixed (patch will be provided within today) wjhan 33 SIFO and MOMS filter incompatibilities (filter length) HM defect closed 2010-08-10T17:54:30+02:00 2010-10-20T05:01:39+02:00 The lengths of the FIR filters SIFO is using have to be the same. Works when adding 6-tap MOMS to the 6-tap SIFO filter set. Adding 4-tap or 6-tap MOMS to the 12-tap SIFO filter sets is conflicting. benjamin.bross@… 37 GPB is not turned off when GPB=0 HM defect davidf closed 2010-08-11T04:59:10+02:00 2010-08-11T11:21:22+02:00 "When --GPB=0 (or in configuration file), tool status shows GPB is turned off, but actually still B-slice is used instead of P-slice. (both in high-delay of GOP 8 and low-delay of GOP 1). Maybe due to the new configuration processing system? P.S. with LowDelayCoding=1, GPB option works. It's strange." wjhan 38 Constructor lacking for DistParam class in TComRdCost.h HM defect closed 2010-08-11T22:18:26+02:00 2010-08-20T08:36:17+02:00 "There is no constructor for DistParam class in TComRdCost.h. Currently, there is a reliance on setting all members to valid values outside this class before computing distortion. For example, this can cause a problem with TComRdCost::getDistPart( Pel* piCur, Int iCurStride, Pel* piOrg, Int iOrgStride, UInt uiBlkWidth, UInt uiBlkHeight, DFunc eDFunc ) function. When this function is called with DF_SADS or DF_HADS variants for eDFunc (I don't think such a call is present in the current code though), the function would return meaningless results and sometimes can cause encoder crash due to memory violation. This is because a member of DistParam class (cDtParam.iStep) is not set. Setting this value to 1 would be reasonable here. The recommendation is to create a constructor for DistParam class. Furthermore, some members (pCb*, pCr*) are never used and can probably be removed to avoid confusion." skanumuri@… 41 Some minor HHI_MRG bugs in 0.6 - already fixed in 0.7 HM defect closed 2010-08-13T12:57:21+02:00 2010-08-13T14:14:59+02:00 "In TEncSearch.cpp between line 1493 and 1494, as well as between line 7039 and 7040, the following three lines need to be added: #if HHI_MRG m_pcEntropyCoder->encodeMergeInfo( pcCU, 0, true ); #endif This fixes the issue, that an incorrect bitrate is estimated for RD-decisions. In TEncEntropy.cpp between line 382 and 383, the following needs to be added: if ( pcCU->getSlice()->isIntra() ) { return; } This avoids the encoding of unwanted merge flags. In TEncEntropy.cpp between line 900 and 901, the following needs to be added: if( bRD ) uiAbsPartIdx = 0; This corrects a wrong determination of merge candidates during the estimation process. All line numbers are valid for version 0.6." Heiner Kirchhoffer 42 parallel V2V (SymbolMode==3) broken in 0.7 HM defect closed 2010-08-13T22:37:50+02:00 2010-10-20T05:11:04+02:00 "Dear Frank, I noticed that the parallel V2V coding (symbolMode : 3) is broken in revision 0.6/0.7. This could be reproduced by setting symbolMode : 3 in the \cfg\encoder*.cfg files, and encoding. By comparing the encoded *.bin bitstream with that generated by setting ""symbolMode : 1"" (CABAC), it was noticed that the V2V bitstream was way bigger than that of the CABAC bitstream, while if V2V worked the way it supposed to be, the two bitstreams should be of the almost the same size. A careful analysis showed that the default setting of multiCodewordThreshold : 96000 # Threshold for multi-codeword coding in the config file caused this problem. In the parallel V2V coding, only one CABAC is used to obtain the statistics for V2V coding, no matter what value ""multiCodewordThreshold"" is set. The fix would be adding a validation check in TAppEncCfg.cpp: Void TAppEncCfg::xCheckParameter() { … if(m_iSymbolMode == 3) { m_uiMCWThreshold = 0; } … } After applying this fix, the size of the encoded bitstream using V2V (symbolMode :3) should be verified as very close to that of CABAC. Besides, we did some improvement/cleaning for the V2V codes based on TMuC 0.7, and we attach the corresponding files \source\App\TAppEncoder\TAppEncCfg.cpp \source\Lib\TLibEncoder\TEncGOP.cpp \source\Lib\TLibEncoder\TEncSlice.cpp \source\Lib\TLibDecoder\TDecTop.cpp Please let us know how the fix/improvement goes, and if there is any problem, do not hesitate to contact us. Best regards, Jinwen " jzan@… 51 Bug in edge based prediction for low complexity HM defect fbossen closed 2010-08-17T16:49:53+02:00 2010-08-31T19:56:25+02:00 "Edge based complexity is currently never used in the low complexity configuration. The following bug fix solves the problem: In the file TComEdgeBased.cpp, the function TComEdgeBased::shift_right_round should be: inline int TComEdgeBased::shift_right_round(int val, int b) { if(b <= 0) return val; else return (val + (1 << (b-1))) >> b; } " virginie.drugeon@… 52 xGetICost Undefined in tcomtrquant.cpp TLibCommon HM defect fbossen closed 2010-08-17T20:31:24+02:00 2010-08-17T21:29:11+02:00 "For tag 0.7.1 when turn off: HHI_TRANSFORM_CODING, QC_MDDT, ROT, RDOQ Symbolmodel = 1; The following error promoted: Error 14 error C3861: 'xGetICost': identifier not found ..\tags\0.7.1\source\lib\tlibcommon\tcomtrquant.cpp 2660 TLibCommon Error 15 error C3861: 'xGetICost': identifier not found ..\tags\0.7.1\source\lib\tlibcommon\tcomtrquant.cpp 2669 TLibCommon " anonymous 54 Encoder crash when setting MAX_CU_DEPTH to 6 HM defect closed 2010-08-18T00:51:25+02:00 2010-08-20T08:49:50+02:00 Issue seems related to HHI_TRANSFORM_CODING. See attached trace. fbossen 64 AMVRES 1/8th 12-tap DCT-IF bug (QC_AMVRES_LOW_COMPLEXTY=0 case) HM defect closed 2010-08-20T12:36:48+02:00 2010-08-21T03:25:15+02:00 "[AMVRES=1 (QC_AMVRES macro = 1), QC_AMVRES_LOW_COMPLEXTY macro = 0] 5/8th position of 12-tap DCT-IF filter is strange: (it should be symmetric values to 3/8th position) Here is the changes: Current 3/8: { -3, 9, -15, 27, -51, 200, 119, -44, 24, -14, 7, -3 }, // 3/8 Current 5/8: { -1, 6, -12, 20, -40, 119, 195, -44, 22, -14, 6, -1 }, // 5/8 Fixed 5/8: (symmetric to 3/8) { -3, 7, -14, 24, -44, 119, 200, -51, 27, -15, 9, -3 }, // 5/8 Fortunately, default value of QC_AMVRES_LOW_COMPLEXTY = 1, so no performance change in default setting with this change." wjhan 65 Memory leak with edge prediction tool HM defect closed 2010-08-20T19:04:36+02:00 2010-08-24T10:24:56+02:00 "As reported by Xiang Li: ""We have a minor memory leak with the edge tool. In tcomprediction.cpp line 100, EdgeBasedPred is never released"". " fbossen 67 Memory leak in TEncSIFO.cpp and TEncAdaptiveLoopFilter.cpp (revision 178) HM defect closed 2010-08-21T13:04:12+02:00 2010-10-20T05:06:29+02:00 "Memory leak was observed in TEncSIFO.cpp and TEncAdaptiveLoopFilter.cpp. With the attached encoder_lowdely.cfg and the patch of memory tracing (in ticket #66, revision 178 based), the memory leak was logged as follows. Memory has not been freed: In TEncSIFO.cpp line 551, memory was allocated at 0x03ab4180 (64B). In TEncSIFO.cpp line 551, memory was allocated at 0x04971fd8 (64B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f1f00 (64B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f1848 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x0468dec0 (2048B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f21b0 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c2f70 (2048B). In TEncSIFO.cpp line 557, memory was allocated at 0x0468d6b8 (2048B). In TEncSIFO.cpp line 576, memory was allocated at 0x04883ff0 (16B). In TEncSIFO.cpp line 557, memory was allocated at 0x03aaf8e0 (18432B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f2460 (64B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f1da8 (64B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f2710 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c2768 (2048B). In TEncSIFO.cpp line 551, memory was allocated at 0x03aaf800 (64B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f2058 (64B). In TEncSIFO.cpp line 576, memory was allocated at 0x047cbff0 (16B). In TEncAdaptiveLoopFilter.cpp line 4188, memory was allocated at 0x007859f0 (128B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f13c0 (64B). In TEncSIFO.cpp line 576, memory was allocated at 0x04866d08 (16B). In TEncSIFO.cpp line 551, memory was allocated at 0x04918fc0 (64B). In TEncSIFO.cpp line 592, memory was allocated at 0x04919fc0 (16B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f2308 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c3f80 (2048B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f2c70 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x03aaaf60 (18432B). In TEncAdaptiveLoopFilter.cpp line 4938, memory was allocated at 0x049eb1b8 (336B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f25b8 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c3778 (2048B). In TEncSIFO.cpp line 557, memory was allocated at 0x0468bea0 (2048B). In TEncAdaptiveLoopFilter.cpp line 5248, memory was allocated at 0x049eeb90 (336B). In TEncAdaptiveLoopFilter.cpp line 5249, memory was allocated at 0x049eed90 (336B). In TEncAdaptiveLoopFilter.cpp line 5250, memory was allocated at 0x049eef90 (168B). In TEncAdaptiveLoopFilter.cpp line 4967, memory was allocated at 0x00785630 (128B). In TEncSIFO.cpp line 551, memory was allocated at 0x03aaae80 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c0f50 (2048B). In TEncSIFO.cpp line 557, memory was allocated at 0x046f5698 (2048B). In TEncSIFO.cpp line 557, memory was allocated at 0x0468b698 (2048B). In TEncAdaptiveLoopFilter.cpp line 4963, memory was allocated at 0x049b1bf8 (336B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f2868 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c0748 (2048B). In TEncSIFO.cpp line 576, memory was allocated at 0x03aa63e0 (16B). In TEncSIFO.cpp line 557, memory was allocated at 0x03aa65e0 (18432B). In TEncSIFO.cpp line 557, memory was allocated at 0x0468ceb0 (2048B). In TEncSIFO.cpp line 551, memory was allocated at 0x03aa6500 (64B). In TEncSIFO.cpp line 557, memory was allocated at 0x04796468 (2048B). In TEncSIFO.cpp line 576, memory was allocated at 0x0489dbc8 (16B). In TEncSIFO.cpp line 551, memory was allocated at 0x04972130 (64B). In TEncSIFO.cpp line 551, memory was allocated at 0x049f19a0 (64B). In TEncAdaptiveLoopFilter.cpp line 5154, memory was allocated at 0x049ef0e8 (168B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c1f60 (2048B). In TEncSIFO.cpp line 557, memory was allocated at 0x0468c6a8 (2048B). In TEncSIFO.cpp line 557, memory was allocated at 0x046c1758 (2048B). In TEncSIFO.cpp line 557, memory was allocated at 0x03ab4260 (18432B). In TEncSIFO.cpp, memory was allocated in initSIFOFilters() with functions like xGet_mem3Ddouble(). Such memory is not released. Moreover, no memory free functions related to xGet_memxDdouble() were provided. In TEncAdaptiveLoopFilter.cpp, if ""if(init == 0)"" and ""init == 0"" are searched, several improper memory allocation can be noticed, where memory is allocated to static local pointers when the related function is called for the first time. Clearly, such memory is not released. It is highly suggested that the proponents for SIFO and AdaptiveLoopFilter also check with other config files before submiting the patch for the memory leak." li@… 69 AMVRES 1/8th 6-tap DCT-IF bug HM defect closed 2010-08-24T02:43:11+02:00 2010-09-08T01:50:38+02:00 "3/8th and 5/8th position coefficients of 6-tap DCT-IF filter have bugs because of typos. The 6 taps coefficients in TMuC 0.71 with QC_AMVRES on. { 11, -42, 196, 118, -36, 10 }, // 3/8 { 10, -36, 196, 118, -42, 11 }, // 5/8 Sum of the coefficients should be 256, while that of current coefficients is 257. The correct coefficients should be { 11, -43, 196, 118, -36, 10 }, // 3/8 { 10, -36, 196, 118, -43, 11 }, // 5/8 " jianle.chen@… 70 ROUNDING_CONTROL_BIPRED encoding time issue HM defect closed 2010-08-24T05:04:47+02:00 2010-08-31T19:55:38+02:00 "I noticed that in TComRdCost.cpp, all the functions for SAD,SSE,HAD where bRound is being passed as parameter, xClip() is being used which affects the encoding time. xClip() is redundant step. (255+255+0)>>1 = 255 and (255+255+1)>>1 = 255. So xClip should be removed from all these functions. For e.g. So in TMuC0.7.2, in TComRdCost.cpp, line 471 can be changed from pred = xClip( (piCur[n] + piRef[n] + bRound) >> 1 ); to pred = (piCur[n] + piRef[n] + bRound) >> 1 ; Results should still be bitexact." rpanchal@… 82 Incorrect MDDT scan LUT for UNIFIED_DIRECTIONAL_INTRA HM defect mcoban closed 2010-08-31T20:22:55+02:00 2010-09-03T20:50:54+02:00 "Currently the dimensions of the MDDT scan LUTs do not match the new prediction modes introduced by UNIFIED_DIRECTIONAL_INTRA. Furthermore the mapping from prediction modes to scans needs to be updated for the UNIFIED_DIRECTIONAL_INTRA. " mcoban 83 Issues with HHI_ALLOW_ROT_SWITCH HM defect closed 2010-09-03T01:48:15+02:00 2010-09-08T02:08:57+02:00 "2 issues appear when disabling HHI_ALLOW_ROT_SWITCH: - code does not compile - TComTrQuant::init does not properly set m_iSymbolMode Simplest resolution seems to remove the macro and keep the code corresponding to its 'on' setting. " fbossen 85 RDOQ and RQT HM defect closed 2010-09-03T08:32:36+02:00 2010-09-08T02:36:55+02:00 "In the RDOQ function TComTrQuant::xRateDistOptQuant the cost of coding the coded block flag is based on m_pcEstBitsSbac->blockCbpBits which is always 1 bit when RQT is enabled [QuadtreeTUFlag:1 in default config] (it is based on a context initialized to a 50/50 probability and which is not used when RQT is enabled and hence never updated). The cost of the coded block flag is thus not taken into account when deciding whether to encode any coefficient at all in a block (which is not necessarily a bad thing by itself). When RQT is disabled the cost of the coded block flag is taken into account as m_pcEstBitsSbac->blockCbpBits is updated according to past history. This has an impact on the comparison of RQT on vs off. In some cases (QP=37) the chroma PSNR was seen to drop by about 1dB when RQT is disabled. The simplest solution may simply be to always ignore the cost of the coded block flag in the RDOQ function. This would not impact the default setting defined in JCT-VC B300. " fbossen 89 Incompatibility between DIF and AMVRES HM defect closed 2010-09-11T22:09:34+02:00 2010-10-20T05:05:13+02:00 "Software currently silently disables adaptive motion vector resolution when directional interpolation filter is used (InterpFilterType=3): [TAppEncCfg.cpp] if(m_iInterpFilterType == IPF_TEN_DIF) m_bUseAMVRes = false; The software should instead produce an error to alert the user than the configuration is not supported. " fbossen 93 Encoder/decoder mismatch when MaxCUsize=8 HM defect closed 2010-09-15T03:46:01+02:00 2010-10-20T05:53:57+02:00 "When Maximum CU size is set to 8 as follows, encoder/decoder mismatch is caused. MaxCUWidth : 8 MaxCUHeight : 8 MaxPartitionDepth : 1 QuadtreeTULog2MaxSize : 3 QuadtreeTULog2MinSize : 2 Other information, - mismatch is caused on all intra coding at least - mismatch is caused with 0.7.3 and 0.8 at least - mismatch is caused in the first few rows of chroma on some frames" j.takiue 94 AIS and UDI incompatibilities HM defect closed 2010-09-29T14:39:43+02:00 2010-10-20T04:38:57+02:00 "For ADI, always enabling smoothing while AIS is disabled (AIS : 0, DEFAULT_IS 1), the table g_aucIntraFilter[iIntraSizeIdx][uiDirMode] is used to determine wether reference samples are filtered once 1, twice 2 or not 0. For UDI with AIS : 0 and DEFAULT_IS 1, reference samples are always filtered once which performs worse than not filtering. Integrating a similar table for smoothing in UDI would solve this issue." bbross 95 Bad encoder estimation for PU based merging. HM defect closed 2010-09-29T15:39:28+02:00 2010-10-20T05:03:29+02:00 "For PU based merging, the encoder now compares the Merge and ME results using different measures for each result, causing bad RD-performance. The same measure should be used for both results. " helle 99 Incompatibility betwenn PU based Merging and PBIC HM defect closed 2010-10-01T01:22:13+02:00 2010-10-20T04:59:37+02:00 "with the recently integrated Fixes for PU based Merging, compatibility between PU based Merging and PBIC is broken. " helle 100 Bug with the selection of MVs for L1 references when AMVP is used HM defect closed 2010-10-09T03:00:28+02:00 2011-02-22T13:47:59+01:00 "In the function predInterSearch() for some cases motion estimation is bypassed (if (iRefList && iRefIdxTemp != iRefIdx[0])). Value of uiBits[iRefList] then does not include the rate of the MV, while uiCostTemp is set to MAX_UINT. The search for the best MVP is called in this case as well (function xCheckBestMVP()) and it can happen that it returns a negative value in uiBitsTemp and this causes integer overflow in uiCostTemp, which wraps around to small values. This leads to cases where this value (that should be MAX_UINT) is smaller than uiCost[0] and a L1 MV wrongly appears to be of a lower cost than L0 MV. This wrap-around small value is in the range of 0xFFFF, so it creates problems in very few cases - only a minor effect on performance, but needs to be tested with a fix. Fix could be simple - just bypass the function xCheckBestMVP() or check whether ME was bypassed when calculating cost." nsprljan 102 Terminating bit should not be coded for LCEC HM defect closed 2010-10-11T11:14:08+02:00 2010-10-17T05:08:59+02:00 For each CU one binary flag is used to indicate whether it is the last CU in a slice. While this is required for CABAC-type coders it is redundant for LCEC. Coding of this flag should be removed in the LCEC case as per current TMuC specification. fbossen 103 -fs (--FrameSkip) command-line option does not work for TAppEncoderStatic HM defect davidf closed 2010-10-12T22:24:42+02:00 2011-04-15T22:18:07+02:00 "Run the following two commands and observe that the frames extracted are identical, although one uses the frame-skip option and one does not. TAppEncoderStatic -c ../cfg/encoder_lowdelay.cfg -c ../cfg/per-sequence/Traffic.cfg -i -f 1 -sym 2 TAppEncoderStatic -c ../cfg/encoder_lowdelay.cfg -c ../cfg/per-sequence/BQMall.cfg -i -fs 10 -f 1 -sym 2" pimthurn 104 "Possible wrong filter coefficients used in DIF for position ""13""" HM defect closed 2010-10-19T03:16:56+02:00 2010-10-20T04:36:30+02:00 "Software version: TMuC 0.8 File TComPredFilter.h Function: __inline Void TComPredFilter::xCTI_FilterDIF_TEN(...) case 13: for (Int y=0; y>7); piSrc += iSrcStride; piDst += iDstStride; } break; Should be changed to: piDst[x*iDstStep] = Clip( (2*piSrcTmp[0*iSrcStride+5] + (-10)*piSrcTmp[1*iSrcStride+4] + 37*piSrcTmp[2*iSrcStride+3] + 111*piSrcTmp[3*iSrcStride+2] + (-15)*piSrcTmp[4*iSrcStride+1] + 3*piSrcTmp[5*iSrcStride+0] + 64)>>7);" dong.lina 105 DIF bug-fix HM defect closed 2010-10-19T08:38:52+02:00 2010-10-20T04:36:03+02:00 Position 13 is interpolated using slightly wrong filter coefficients instead of the correct coefficients: [2 -10 37 111 -15 3] kemalu 106 Bug on mapping intra direction (from 34 to 9 case) HM defect closed 2010-10-27T05:07:32+02:00 2010-11-10T08:11:11+01:00 "Jani reported the bug on mapping intra direction from 34 to 9 case. In the case of conversion to 9 modes, horizontal mode with angle 7 (right-down variants) should be mapped to the mode 3 (right-down), but now it is mapped to mode 6 (left-down). [TComRom.cpp] const UChar g_aucAngModeMapping[3][34] = // intra mode conversion for most probable { {2,3,2,2,4, 4,4,0,0,0, 0,0,0,0,2, 2,2,2,2,2, 2,1,1,1,1, 1,1,1,1,1, 2,2,2,2}, // conversion to 5 modes {2,3,3,2,4, 4,4,2,0,0, 0,2,5,5,5, 2,6,6,'''6''',2, 7,7,7,2,1, 1,1,2,8,8, 8,2,2,2}, // conversion to 9 modes {2,3,3,10,10, 4,11,11,0,0, 0,12,12,5,5, 13,13,6,14,14, 7,7,15,15,1, 1,1,16,16,8, 8,2,2,9} // conversion to 17 modes }; should be const UChar g_aucAngModeMapping[3][34] = // intra mode conversion for most probable { {2,3,2,2,4, 4,4,0,0,0, 0,0,0,0,2, 2,2,2,2,2, 2,1,1,1,1, 1,1,1,1,1, 2,2,2,2}, // conversion to 5 modes {2,3,3,2,4, 4,4,2,0,0, 0,2,5,5,5, 2,6,6,'''3''',2, 7,7,7,2,1, 1,1,2,8,8, 8,2,2,2}, // conversion to 9 modes {2,3,3,10,10, 4,11,11,0,0, 0,12,12,5,5, 13,13,6,14,14, 7,7,15,15,1, 1,1,16,16,8, 8,2,2,9} // conversion to 17 modes };" wjhan 107 Crash when TAppEncoder.exe --help HM defect closed 2010-11-03T09:44:29+01:00 2010-12-20T19:56:20+01:00 "When execute ""TAppEncoder.exe --help"" or TAppEncoder.exe without any parameter, the encoder will crash. This is because in some destructors m_pcEncCfg is used without checking whether it is NULL." Xiang Li 109 One potential bug may lead to mismatch HM defect closed 2010-11-18T12:31:53+01:00 2012-08-20T16:01:11+02:00 "At encoder, both skip mode and direct mode are checked in xCheckRDCostSkip(). When the encoder selects the bi-predicted direct mode and this CU has no residue (it will only happen with CABAC, when the encoder thinks this direct mode will cost less bits than skip mode), the variables should be reset as the skip mode. Actually, when this happens, xEncodeCU() will take it as skip mode, and the decoder will receive skip mode too. But at the encoder TransformIdx may not always be 0 (because in RD process, the encoder takes it as direct mode, not skip mode), at the decoder TransformIdx will always be 0(because the decoder takes it as skip mode). This will lead to mismatch after deblocking filter. So, in my opinion, after the RD process, when pcCU->isSkipped( uiAbsPartIdx ) is true, the variables should be reset as the skip mode, to avoid the mismatch between the encoder and the decoder." libin 110 Bug in AMVP HM defect closed 2010-11-18T14:52:29+01:00 2010-12-21T19:40:02+01:00 "In function xGetTemplateCost function, encoder always uses DCT-IF filter in AMVP cost calculation even if the motion comp. filter is different. The fix would look like: #if BUGFIX InterpFilterType ePFilt = (InterpFilterType)pcCU->getSlice()->getInterpFilterType(); switch ( ePFilt ) { case IPF_TEN_DIF: xPredInterLumaBlk_TEN ( pcCU, pcPicYuvRef, uiPartAddr, &cMvCand, iSizeX, iSizeY, pcTemplateCand ); break; default: xPredInterLumaBlk ( pcCU, pcPicYuvRef, uiPartAddr, &cMvCand, iSizeX, iSizeY, pcTemplateCand ); } #else xPredInterLumaBlk ( pcCU, pcPicYuvRef, uiPartAddr, &cMvCand, iSizeX, iSizeY, pcTemplateCand ); #endif " kemalu 111 Redundant codes in motion estimation of DCT-IF HM defect closed 2010-11-19T02:10:06+01:00 2010-12-07T20:50:18+01:00 "The codes in “TEncSearch.cpp”from line 8472 to 8492 are redundant and should be removed. Although the encoding result is identical, the encoding time is increased. case 1: { // Quater-pel interpolation : vertical piSrcYPel = piSrcPel - m_iDIFHalfTap; piDstY = piSrc-m_iDIFTap2 - iSrcStride; xCTI_FilterQuarter0Ver(piSrcYPel, iSrcPelStride, 1, iWidth + m_iDIFTap, iHeight, iSrcStride4, 4, piDstY); piSrcYPel = piSrcPel - m_iDIFHalfTap; piDstY = piSrc-m_iDIFTap2 + iSrcStride; xCTI_FilterQuarter1Ver(piSrcYPel, iSrcPelStride, 1, iWidth + m_iDIFTap, iHeight, iSrcStride4, 4, piDstY); // Left three pixels piSrcY = piSrc-4 - iSrcStride; piDstYPel = piDst-1 - iDstStride; xCTI_FilterQuarter1Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); piSrcY = piSrc-4; piDstYPel = piDst-1; xCTI_FilterQuarter1Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); piSrcY = piSrc-4 + iSrcStride; piDstYPel = piDst-1 + iDstStride; xCTI_FilterQuarter1Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); // Middle two pixels piSrcY = piSrc - iSrcStride; piDstYPel = piDst - iDstStride; Int iSrcStride2 = (iSrcStride<<1); Int iDstStride2 = (iDstStride<<1); for (y=0; y < iHeight*2; y++) { for (x=0; x < iWidth; x++) { piDstYPel[x*4] = Clip( (piSrcY[x*4] + 128) >> 8 ); } piSrcY+=iSrcStride2; piDstYPel+=iDstStride2; } // Right three pixels piSrcY = piSrc - iSrcStride; piDstYPel = piDst+1 - iDstStride; xCTI_FilterQuarter0Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); piSrcY = piSrc; piDstYPel = piDst+1; xCTI_FilterQuarter0Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); piSrcY = piSrc + iSrcStride; piDstYPel = piDst+1 + iDstStride; xCTI_FilterQuarter0Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); /* These codes are redundant // Right three pixels piSrcY = piSrc - iSrcStride; piDstYPel = piDst+1 - iDstStride; xCTI_FilterQuarter0Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); piSrcY = piSrc; piDstYPel = piDst+1; xCTI_FilterQuarter0Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); piSrcY = piSrc + iSrcStride; piDstYPel = piDst+1 + iDstStride; xCTI_FilterQuarter0Hor(piSrcY, iSrcStride4, 4, iWidth, iHeight, iDstStride4, 4, piDstYPel); // Middle two pixels piSrcYPel = piSrcPel; piDstYPel = piDst - iDstStride; xCTI_FilterQuarter0Ver(piSrcYPel, iSrcPelStride, 1, iWidth, iHeight, iDstStride4, 4, piDstYPel); piSrcYPel = piSrcPel; piDstYPel = piDst + iDstStride; xCTI_FilterQuarter1Ver(piSrcYPel, iSrcPelStride, 1, iWidth, iHeight, iDstStride4, 4, piDstYPel); */ break; } " chujoh 112 Combined coding of RefFrmIdx & InterDir (LCEC) for P slices does not work HM defect closed 2010-12-06T16:29:49+01:00 2010-12-21T19:41:41+01:00 "The fix is to do combined coding only for B slices. This does not affect simulations under common coding conditions. The fix is attached. " afuldseth 114 Encoder decoder mismatch when GBP = 0 HM defect closed 2010-12-13T09:03:36+01:00 2010-12-21T19:42:38+01:00 When GBP = 0 in the encoder config file, some of the sequences are giving encoder decoder mismatch (e.g. BQSquare all the QP's). kemalu 117 AMVP bug in rectangular (2NxN and Nx2N) partition mode HM defect closed 2010-12-21T10:36:27+01:00 2011-01-25T07:31:04+01:00 "Messages from Minhua: In the TMuC TComDataCU.cpp, fillMvpCand() ----- the mvp list is reordered if the partition is 2NxN or Nx2N. Line 3915- else if ( ( ((eCUMode == SIZE_2NxN) || (eCUMode == SIZE_2NxnU) || (eCUMode == SIZE_2NxnD)) && uiPartIdx == 0 '''&& m_pcSlice->isEqualRef(eRefPicList, m_cMvFieldB.getRefIdx(), iRefIdx)''' ) && iAboveMvIdx > 0 ) { cTempMv = pInfo->m_acMvCand[0]; pInfo->m_acMvCand[0] = pInfo->m_acMvCand[iAboveMvIdx]; pInfo->m_acMvCand[iAboveMvIdx] = cTempMv; } else if ( ( ((eCUMode == SIZE_Nx2N) || (eCUMode == SIZE_nLx2N) || (eCUMode == SIZE_nRx2N)) && uiPartIdx == 1 '''&& m_pcSlice->isEqualRef(eRefPicList, m_cMvFieldC.getRefIdx(), iRefIdx)''') && iCornerMvIdx > 0 ) { cTempMv = pInfo->m_acMvCand[0]; pInfo->m_acMvCand[0] = pInfo->m_acMvCand[iCornerMvIdx]; pInfo->m_acMvCand[iCornerMvIdx] = cTempMv; } The condition (I marked bold) seems incorrect. m_cMvFieldB and m_cMvFieldC aren't initialized in the decoding process, so these conditions are never fulfilled. And my suggestion: The goal of these 'boldface' checks is to check the equality of two reference indices, but as Minhua indicated, they does not work due to the non-initialization. Furthermore, the next conditions iAboveMvIdx > 0 and iCornerMvIdx > 0 already do the same thing. Thus instead of initializing them correctly, simply removal of the bold parts is sufficient to get the original motivation to use the AVC-style motion predictor as the 1st place in AMVP queue for rectangular partition modes. " wjhan 119 A bug in chroma deblocking HM defect Andrey Norkin closed 2011-01-07T14:27:59+01:00 2011-01-25T07:28:11+01:00 When CU size is 8, m_aapucBS[iDir][0][uiBsAbsIdx] for some values of uiBsAbsIdx are accessed before being calculated. andreyn 121 m_iInterpFilterType may be used uninitialized HM defect closed 2011-02-08T03:01:10+01:00 2011-02-08T04:28:02+01:00 "It is currently possible that TAppEncCfg::m_iInterpFilterType is used without initialization, since this is no longer a configurable option. This may cause some assertions to be false, e.g., in writing the interpolation filter type to the SH. A quick fix is to initialize TAppEncCfg::m_iInterpFilterType to 0 in the constructor. It may also be desirable to stop writing/reading the InterFilterType in the SH. " chyeo 122 Decoder crash for 10-bit sequences for low QPs HM defect closed 2011-02-15T12:15:47+01:00 2011-02-21T01:58:01+01:00 "- NebutaFestival QP2 INTRA 50fr - NebutaFestival QP2 Random 50fr" tung.nguyen 124 Finding Natural Tips on how to To Give Up Smoking HM defect closed 2011-02-18T14:09:14+01:00 2011-02-20T20:53:47+01:00 "Finding Natural Tips on how to To Give Up Smoking Are you looking for an choice to result from your current smoking practice? If so, you should often be informed connected with the actual fact in which it's not just for a person and loads of folks world wide, who may have the particular very same goal. Yet, only a number of have the ability to stop smoking cigarettes and come using this dependency to cigarettes. If you get in to barefoot jogging, you might find the idea harder compared to a person estimated, most likely, you might definitely not have the ability to succeed in your intention. Perhaps, you will stop smoking cigarettes for any although along with all over again pick it up at some time of time. While there are actually thousands regarding plans along with solutions inside the market place, which in turn ensure you a good outcome in relation to stop smoking cigarettes, just one or two have the ability to provide satisfying effects with the end users. Also, if you are utilizing a strong alternative product with out very good knowledge, you might have got to expertise a lot of adverse reactions. Yet, in such a content material, you might manage to find a number of organic solutions to stop smoking. Everyone is going to be capable of consider all these techniques, while there are actually no area side effects inside the idea. A large number of folks, whom adequately utilized these kind of natural methods, ended up being competent to accomplish his or her objectives of stop smoking help. Also, these techniques usually are less complicated when compared with alternative alternatives which have been readily available within the market place for you to find clear regarding cigarette smoking. Your very first action that will you've got for you to look at when preparing to give up cigarettes will be, locating a great motive to get out of that habit. If you don't include the proper intentions, you might not have the ability to obtain your goals. In the actual various other hand, in the event that a person is making a person to give up, nevertheless , you tend not to sense motivated from your unique self, it can impede your advance. Your mental technique works an crucial purpose around encouraging anyone to to give up smoking. Listed below posted are a few natural ways to stop smoking: Licorice: Several scientific evidences and lots of associated with the people who smoke , acknowledge that licorice is able to support these folks get out of the smoking. It is possible to use a branches in the licorice basic at the time you have a very craving for some sort of cigarette smoking. Yet, be certain you will be utilizing the idea reasonably. Celery: Next time period whenever you think similar to smoking, munch a new carrot alternatively. As a result, preserve little baggies connected with celery within your motor vehicle whenever you get out involving your house. Celery may offer you actually wide variety of well being advantages. Also, they will can also make it easier to with the by mouth fixation, which often frequently will come whenever you need to have a new cigarette. Green clover: Red clover is also deemed while a cancer preventer. This can also support somebody to stop using smokeless cigarette or maybe smoking. Rather then cigarette, chewing the leaves regarding red clover could assist you to conquer the behavior simply. The particular above-mentioned are generally a few of the basic and also easy suggestions that could assist you to to come out and about regarding the smoking behavior. Yet, as mentioned above, you should in addition have the proper psychological frame of mind for you to come out there regarding this kind of pattern. Using the assistance regarding a stop smoking Hypnosis programs is also an incredible approach to obtain positive outcomes. " tcqlxfstnm0 126 Disabling NxN split modes should be more generic HM defect closed 2011-02-21T01:59:15+01:00 2011-03-20T10:17:46+01:00 Currently the code for disabling NxN modes for CUs larger than the smallest CU assumes that the smallest CU has size 8x8. This should be made more generic. fbossen 127 Harmonization of macros for temporal MV predictor HM defect closed 2011-02-21T02:02:15+01:00 2011-02-21T22:14:31+01:00 When FT_TCTR is disabled and PANASONIC_AMVPTEMPORALEXT is enabled, the derivation of the temporal MV predictor is inconsistent (in merge mode). A macro similar to FT_TCTR_MERGE should be added to cover this case. fbossen 130 Decoder crash with GPB=0 and LCEC in low-delay configs HM defect closed 2011-02-24T08:11:43+01:00 2011-02-27T19:37:24+01:00 Crash seems related to MS_LCEC_LOOKUP_TABLE_EXCEPTION macro (seems to work fine when this macro is disabled, not tested extensively). fbossen 131 Assertion failure with MRG=0 HM defect closed 2011-02-24T08:23:50+01:00 2011-05-17T20:14:45+02:00 "Assertion failed: (0), function xWeightedAverage, file HM-2.0-dev/source/Lib/TLibCommon/TComPrediction.cpp, line 1375. Seems to happen with all configurations (except intra only)" fbossen 133 One bug related to QC_LCEC_INTER_MODE HM defect closed 2011-03-01T04:29:09+01:00 2011-03-22T12:31:26+01:00 "One bug related to “#define QC_LCEC_INTER_MODE 1” was found. When the default CU size and depth are changed(such as CU size 16,depth 2), the decoder will crash. That is caused by when it is the last depth; the LCEC should use the last table, where there is no split flag. The bug fix can be found attached, under the macro of LCEC_INTER_MODE_BUG_FIX. " libin 137 Encoder crashs on faulty command line input parameter HM defect davidf closed 2011-03-30T15:37:13+02:00 2011-04-15T02:42:39+02:00 "Example: -c encoder_intra.cfg -c per-sequence\BQSquare.cfg -q 22 - f 10" tung.nguyen 138 valgrind failures in HM-2.1, HM-2.2 and HM-3.0-dev HM defect davidf closed 2011-03-30T16:31:50+02:00 2011-04-16T12:41:06+02:00 "There are numerous valgrind errors when running these versions, based on values not being initialised, apparently in EncIntraHeader (TEncSearch.cpp). HM-2.0 is free of such errors. HM-2.0-dev-mediatek seems to have introduced at least some of these errors." thomasd 139 Memory leak in Void TComAdaptiveLoopFilter::create HM defect closed 2011-04-06T08:17:33+02:00 2011-04-15T08:41:45+02:00 "Memory leak in TComAdaptiveLoopFilter::create was reported by valgrind. In fact, m_imgY_temp was allocated in TComAdaptiveLoopFilter::create but was never freed. It is quite easy to fix this bug: Add the following line in bold into Void TComAdaptiveLoopFilter::destroy(), namely Void TComAdaptiveLoopFilter::destroy() { ... '''destroyMatrix_int(m_imgY_temp)'''; destroyMatrix_int(m_filterCoeffSym); ... } According to valgrind, there are other minor memory leak. But they are not serious. " Xiang Li 141 Annoying C4819 warnings when compiled with MS Visual C++ HM defect fbossen closed 2011-04-06T11:29:09+02:00 2011-04-15T08:53:42+02:00 "At the end of 4th line of copyright message in each file, there is a character whose character code is `0xC2'. This produces annoying C4819 warning when it is compiled with (at least Japanese version of) MS Visual C++, though it is not displayed. What does the character mean? Is it really necessary as a part of copyright message? If not, could you remove it? " hao 142 bug of dQP coding in LCEC HM defect closed 2011-04-13T02:12:01+02:00 2011-05-17T20:15:47+02:00 "Currently, dQP is encoded first by a flag indicating zero or nonzero dQP. If the flag shows nonzero dQP then the value of dQP is encoded by mapping a signed dQP to an unsigned codenumber. Then these codenumbers are encoded by unary code. For LCEC, xWriteSvlc( iDQp ) from Void TEncCavlc::codeDeltaQP( TComDataCU* pcCU, UInt uiAbsPartIdx ) is using the mapping UInt xConvertToUInt ( Int iValue ) { return ( iValue <= 0) ? -iValue<<1 : (iValue<<1)-1; } The LCEC mapping is: 1->1, -1->2,2->3, -2->4.... The mapping used in CABAC is shown as the line below in Void TEncSbac::codeDeltaQP( TComDataCU* pcCU, UInt uiAbsPartIdx ) UInt uiDQp = (UInt)( iDQp > 0 ? ( 2 * iDQp - 2 ) : ( -2 * iDQp - 1 ) ); The CABAC mapping is: 1->0, -1->1,2->2, -2->3.... The problem is that LCEC mapping wastes the codenumber==0 and spends more bits to encode nonzero dQPs. Solution is to use the CABAC mapping for LCEC case to save bits. " junxu 163 bug related to GOP size setting HM defect closed 2011-05-17T07:28:42+02:00 2011-06-03T00:39:23+02:00 "When using random access configuration, setting GOPSize=16 and RateGOPSize=8, the decoder crashed. That is caused by for frame 8, at the encoder side, the reference frame list is [L0 0 16 ] [L1 0 16 ] [LC 0 16 ], which is treated as low delay B frame; but at the decoder side, the reference frame list is constructed as [L0 0 16 ] [L1 16 0 ] [LC 0 16 ], which is traditional B frame. In my opinion, the fix can be // store lambda m_pcRdCost ->setLambda( dLambda ); m_pcTrQuant->setLambda( dLambda ); rpcSlice ->setLambda( dLambda ); '''#if BUG_FIX_GOP_SIZE''' if ( rpcSlice->getPOC()%m_pcCfg->getGOPSize() == 0 ) { eSliceType = P_SLICE; } else { eSliceType = B_SLICE; } eSliceType = (iPOCLast == 0 || uiPOCCurr % m_pcCfg->getIntraPeriod() == 0 || m_pcGOPEncoder->getGOPSize() == 0) ? I_SLICE : eSliceType; rpcSlice->setSliceType ( eSliceType ); '''#endif''' around line 353 in TEncSlice::initEncSlice()." libin 172 HM3.1 SAO and multiple SPS/PPS HM defect closed 2011-05-26T12:28:24+02:00 2011-10-19T13:06:44+02:00 "In HM3.1, if TEncGOP.cpp is modified to code a PPS and SPS with every frame, by commenting out the guard by m_bSeqFirst at line 427, then the decoder will decode but reports MD5 mismatches. When SAO is turned off, these MD5 mismatches disappear. Running the decoder with valgrind returns the error: ==16136== Conditional jump or move depends on uninitialised value(s) ==16136== at 0x41697A: TComSampleAdaptiveOffset::xProcessQuadTreeAo(unsigned int, TComPicYuv*, TComPicYuv*) (TComAdaptiveLoopFilter.cpp:3443) ==16136== by 0x4184CA: TComSampleAdaptiveOffset::SAOProcess(TComPic*, _SaoParam*) (TComAdaptiveLoopFilter.cpp:3523) ==16136== by 0x46F2AC: TDecGop::decompressGop(TComInputBitstream*, TComPic*&, bool) (TDecGop.cpp:189) ==16136== by 0x477A68: TDecTop::executeDeblockAndAlf(unsigned int&, TComList*&, int&, int&) (TDecTop.cpp:196) ==16136== by 0x40666C: TAppDecTop::decode() (TAppDecTop.cpp:139) ==16136== by 0x4036A7: main (decmain.cpp:76) An example command line is : ./hm-enc -c encoder_intra_loco.cfg -c racehorses-c.cfg -i /master/hevc-test-pictures/RaceHorses_832x480_30.yuv -o test.yuv -b test.bit --FramesToBeEncoded=9 [--SAO=0] The output of the decoder is still viewable and differs only by small values from the encoder local output, suggesting it is indeed SAO that is at fault. Thomas Davies thdavies@cisco.com " thomasd 173 More contexts defined for CABAC than actually used HM defect closed 2011-05-27T22:27:51+02:00 2011-08-17T08:34:09+02:00 ContextTables.h defines more context than are in use. In particular values of NUM_QT_CBF_CTX, NUM_ONE_FLAG_CTX and NUM_ABS_FLAG_CTX are too large. fbossen 175 Clipping in removeHighFreq considered slightly harmful HM defect closed 2011-05-29T17:12:34+02:00 2012-02-29T07:18:01+01:00 "Function `TComYuv::removeHighFreq` is called only during ME for bipredictive case, where clipping of the unidirectional part is done as in the following: {{{ pDst[x ] = xClip( (pDst[x ]<<1) - pSrc[x ] ); }}} This makes the prediction operation to be (O is the predicted signal, R1 and R2 are references): {{{ (clip(2*O - R1) - R2 )/ 2 }}} When clipping is omitted, results for 24 frames are as follows (based on `HM-3.0-dev`): {{{ Random access Random access LoCo Y BD-rateU BD-rateV BD-rateY BD-rateU BD-rateV BD-rate Class A 0.0 0.0 0.2 0.0 -0.1 -0.2 Class B 0.1 -0.1 -0.1 0.0 -0.1 0.1 Class C -0.1 -0.3 0.1 0.0 -0.5 -0.3 Class D 0.0 -0.4 -0.3 -0.2 -0.2 -0.6 All 0.0 -0.2 -0.1 -0.1 -0.2 -0.2 Low delay Low delay LoCo Y BD-rateU BD-rateV BD-rateY BD-rateU BD-rateV BD-rate Class B -0.1 -0.3 -0.1 0.0 0.1 0.2 Class C 0.0 0.2 -0.1 0.0 0.2 0.2 Class D 0.0 0.0 0.4 -0.2 -0.2 -0.6 Class E -0.1 0.1 -0.2 0.0 -0.1 0.2 All -0.1 0.0 0.0 0.0 0.0 0.0 }}}" nsprljan 183 Incorrect encoder slice size decisions when EntropySliceMode=2 HM defect closed 2011-06-09T18:19:37+02:00 2011-06-22T14:14:52+02:00 "This is a problem in the HM-3.1-dev-dqp branch. When using EntropySliceMode 2, i.e. fixed number of bits (for VLC) or bins (for CABAC) per slice, CompressCU will sometimes produce CU:s too large to fit in a slice, resulting in slices larger than the specified limit. This could be avoided if the encoder made the decision to split the CU (unless the CU is already of slice granularity size or smaller). A split decision check is already implemented in xCheckBestMode for regular slices, but no similar check is performed for entropy slices. The fix for this would be to add a similar check for entropy slices. Note that for this to work for CABAC where a bin threshold is used, code to keep track of the number of bins encoded during compression is needed too." rickard 338 Uninitial m_uiMaxLatencyIncrease HM defect closed 2012-02-25T07:34:24+01:00 2012-02-29T17:28:59+01:00 "In the branch HM-5.2-dev-core: Signaling DPB parameters for each temporal layer (JCTVC-H0567). Submitted by Rickard Sjoberg (rickard.sjoberg@ericsson.com) --------------------------------------------------------- Here m_uiMaxLatencyIncrease is not initial on Encoder." chenm003 405 SVN r2113 bug HM defect closed 2012-03-15T05:22:04+01:00 2012-03-23T13:45:37+01:00 "In the SVN r2113, there have a code below: xConfirmPara( m_bUseLComb==false && m_numReorderPics!=0, ""ListCombination can only be 0 in low delay coding (more precisely when L0 and L1 are identical)"" ); but here numReorderPics is array, so the release version HM can't running on Windows." chenm003 782 compile problem of HTM 5.1 under CentOS HM defect closed 2012-09-27T15:13:21+02:00 2012-09-29T17:17:29+02:00 "When I compile 3DV-HTM 5.1 under linux, it has some error message make[1]: *** [objects/TRenModel.d.o] Error 1 make[1]: Leaving directory 'HTM/build/linux/lib/TLibRenderer' make: *** [all] Error 2 How could I solve this problem? (My OS is CentOS.)" cttsai 34 Configurability of scanning method and context model (as 0.7+) HM enhancement closed 2010-08-11T03:57:38+02:00 2010-10-20T04:56:34+02:00 "TMuC supports a new context modeling for the transform coefficients and an adaptive scanning methods. But now they are controlled by a single macro, HHI_TRANSFORM_CODING, although they are different coding tools and can be separated easily. We suggest to separate one macro into two macros: HHI_TRANSFORM_SCAN and HHI_TRANSFORM_CONTEXT_MODEL to improve the configurability of the software. Or, to have a backward compatibility, adding HHI_TRANSFORM_SCAN to turn on/off adaptive scanning inside the original MACRO is also ok." wjhan 35 Improved configurability of residual quadtree HM enhancement closed 2010-08-11T04:50:07+02:00 2010-10-20T04:55:51+02:00 "According to the residual quadtree concept, for the given CU, various TU size is evaluated in the quadtree style. In the configuration file, two parameters are given: QuadtreeTULog2MaxSize QuadtreeTULog2MinSize where they specify the maximum and minimum possible transform sizes, respectively. It is a good feature, however, it can be improved further. For example, for 64x64 PU, all transform sizes of 4x4, 8x8, 16x16, 32x32 and 64x64 are evaluated when RQT=1. It slows encoder a lot. We suggest to add one another way to configure residual quadtree: maximum allowed depth of residual quadtree such as: QuadtreeTUMaxDepth If we set QuadtreeTUMaxDepth=3, 64x64, 32x32 and 16x16 are used for 64x64 CU while 16x16, 8x8 and 4x4 are used for 16x16 CU. It is helpful to reduce the encoder complexity. It should be noted that it does not change RQT itself, but just encoder behaviour. And if we set QuadtreeTUMaxDepth sufficiently large value, it should have the same results in the previous version. This feature is also useful in TE9 to check variable aspects of the TU structure." wjhan 39 9 intra prediction mode HM enhancement fbossen closed 2010-08-12T06:20:47+02:00 2010-10-20T04:40:16+02:00 please introduce configuration for only using 9 intra prediction modes anonymous 53 Split ROUNDING_CONTROL macro into two macros HM enhancement closed 2010-08-17T23:30:35+02:00 2010-08-18T21:46:54+02:00 "Split ROUNDING_CONTROL macro into a macro for bi-prediction rounding control and another for transform bit-depth expansion. This will improve clarity of the code without any effect on performance or speed." rajanj@… 57 Excessive memory allocation HM enhancement closed 2010-08-19T00:12:11+02:00 2014-09-12T16:22:10+02:00 "Memory allocation is excessive, possibly leading to crashes. Memory usage has been analyzed for the following case: class B encoding with max CU=32x32, memory snapshot during encoding of 2nd frame - Transform coefficients: 9 TComList objects 2040 CUs per frame 3 32x32 integer arrays per CU (luma+2*chroma), each array is 4KB 9 * 2040 * 3 * 32 * 32 * 4 = 215MB - Luma frame buffers: 40 * 4.48MB = 179MB - Chroma frame buffers: 79 * 1.12MB = 89MB - Bitstream buffers (TComBitStream objects): 8 * 11.87MB = 95MB Also see attached jpeg file " fbossen 60 Configurability of chroma interpolation filter HM enhancement closed 2010-08-20T06:57:04+02:00 2010-10-20T04:57:38+02:00 "Current software uses bi-linear interpolation filter for chroma when InterpFilterType=0, 3 and 4 while luma 1/8th filter is used for InterpFilterType=1 and 2. Configurability of the use of luma 1/8th interpolation filter for chroma (possibly different default number of taps of chroma, but not new filter) is preferable. " wjhan 61 Configurability of MDDT and ROT HM enhancement closed 2010-08-20T07:02:38+02:00 2010-10-20T04:57:03+02:00 "Current TMuC uses MDDT for 4x4/8x8 and ROT for other sizes. It was suggested to allow two coding tools as it was proposed in CfP - MDDT for 4x4/8x8, ROT for all sizes. (It is easy since ROT is 2nd transform after any kind of first transform) Configurability to allow testing this feature is useful to identify the validity of the unified design of TMuC." wjhan 62 Configurability of TU across PU HM enhancement closed 2010-08-20T07:10:49+02:00 2010-10-20T05:15:56+02:00 "It was suggested to add enabling/disabling the case of TU across PU. Since current TE12 plans to test both RQT=0/1, it is preferable to add this feature for both RQT=0/1. (C.f. RQT=1 case, this feature is same to HHI_RQT_FORCE_SPLIT_ACC2_PU macro in 0.5-hhi branch. For RQT=0 case, it is a simple change on top of it.) " wjhan 63 Configurability of PU partition HM enhancement closed 2010-08-20T07:15:10+02:00 2010-10-20T05:09:25+02:00 "It was suggested to enabling/disabling PU partitions as: - Enable/disable Inter 2NxN and Inter Nx2N - Enable/disable Inter NxN - Enable/disable Intra NxN All changes should have syntax change, thus the first and second item may not be totally independent macros." wjhan 66 Tracing memory allocation HM enhancement closed 2010-08-20T20:25:27+02:00 2012-08-20T15:58:38+02:00 "Recently, we have many problems related to improper memory usage, such as memory leak (ticket #13,#14,#18,#19,#65), excessive memory allocation (ticket #57), too many times of memory allocation (ticket #21). To ease the detection of memory problems, a memory tracing tool is proposed. A patch based on revision 176 is attached (most of revisions are replacement of conventional memory allocation functions with new macros). The features of the tool are as follows. 1, Log of memory leak (file and line). 2, Log of memory usage (how much memory is allocated and times of memory allocation) during encoding/decoding. 3, Log of memory usage of each cpp/h file. 4, Print out the memory usage information during encoding/decoding. Further features can be easily added if necessary. With the memory log information, any memory leak or improper memory usage can be easily noticed by algorithm proponents and software coordinators. The tool is easy to use. After including tool_tracemem.cpp and tool_tracemem.h into source/Lib/TLibCommon, what you have to do is using new macro MEMNEW/MEMDELETE to replace the conventional new/delete. " li@… 86 fWeight in TEncSearch::xMotionEstimation (TMuC 0.7) HM enhancement closed 2010-09-08T11:38:10+02:00 2015-03-26T15:04:25+01:00 "At the end of function TEncSearch::xMotionEstimation, we have the following line ruiCost = (UInt)( floor( fWeight * ( (Double)ruiCost - (Double)m_pcRdCost->getCost( uiMvBits ) ) ) + (Double)m_pcRdCost->getCost( ruiBits ) ); For P and B frames, fWeight=1 and 0.5, respectively. When we calculate the distortion (SAD/HAD) for B frames in motion estimation, we already used the average prediction of two hypotheses, such as in TComRdCost::xGetSADs32(). Then fWeight should also be set to 1 for B frames. To keep the original design (fWeight=0.5 for B frames) unchanged, during the calculation of sub-pixel distortion such as TComRdCost::xCalcHADs8x8, a one-bit left shift is applied after the difference calculation, i.e., pred = xClip( (piCur[i*iStep] + piRef[i] + bRound) >> 1 ); diff[k+i] = (piOrg[i] - pred) << 1; which compensates the setting of fWeight=0.5. Such an implementation (fWeight=0.5 + one-bit left shift) is correct. However, the code is confused and difficult to understand. We hope it can be improved to be more clear. For example, set fWeight=1 for B frames while removing the left shift in functions like TComRdCost::xCalcHADs8x8. " Xiang Li 88 Merging and skip/direct configurability HM enhancement closed 2010-09-09T01:47:03+02:00 2010-10-20T05:10:17+02:00 "Currently, skip and direct modes are turned off when merging is used. For TE11, new configuration using both merging and skip/direct is needed. With this feature, three possible ways can be tested: 1. merging only 2. skip/direct 3. merging + skip/direct (for TE11) " wjhan 92 Encoder Speed for SIFO HM enhancement closed 2010-09-14T23:42:12+02:00 2010-10-20T04:50:56+02:00 "While running TE12 tests it is noticed that SIFO is slower compared to other interpolation filters. Basically increase in speed is because of multiple ME for different offsets in SIFO. It can be speedup up by a very small code change in encoder only. (No syntax changes) After speedup SIFO speed will be same as other interpolation method. The macro to fix this issue is ""SIFO_ENC_SPEEDUP""" rahul 96 redundant coding of RQT-root flag HM enhancement closed 2010-09-30T20:35:08+02:00 2010-10-20T05:35:42+02:00 "RQT-root flag does not have to be coded in Direct mode with InterDir=3. " helle 97 coding of merge-flags in PU based Merging HM enhancement closed 2010-09-30T20:44:44+02:00 2010-10-20T05:04:02+02:00 "In PU-based Merging, all merge-flag configurations inside a CU resulting in a CU-partitioning that could also be coded by ""part-size""-signalization should be avoided. " helle 98 restricted Predictor List for skip/direct modes when Merge is active HM enhancement closed 2010-09-30T20:51:12+02:00 2010-10-20T05:35:20+02:00 "When skip/direct modes are active together with Merge, coding-efficiency is possibly improved when skip/direct modes use a restricted predictor list. " helle 101 Function getPartIndexAndSize() cannot be used at the decoder HM enhancement closed 2010-10-09T10:47:08+02:00 2014-11-11T12:02:19+01:00 "At the encoder CUs are split into smaller CUs and then the upper left corner of each CU can be indexed with a 0, instead with uiAbsPartIdx. In function getPartIndexAndSize() a fixed value of 0 is used instead of uiAbsPartIdx, which is fine as the function is currently only used at the encoder. At the decoder this kind of splitting is not performed, but the CUs are split by referencing to the positions in the LCU, so if this function is used it does not produce correct results. This can be fixed by replacing the zeroes at all required places with uiAbsPartIdx, and make that variable an input parameter to the function. The modified function is provided in the attachment." nsprljan 115 Disable L1 search for RA HM enhancement closed 2010-12-17T11:07:03+01:00 2010-12-21T19:40:46+01:00 "I have used 0.9-hm branch r389, but it should apply to the most recent release as well. All changes are in TEncSearch::predInterSearch only. 1.Instead of: #if GPB_SIMPLE_UNI if ( pcCU->getSlice()->getSPS()->getUseLDC() ) { ... } else { xMotionEstimation ( pcCU, pcOrgYuv, iPartIdx, eRefPicList, &cMvPred[iRefList][iRefIdxTemp], iRefIdxTemp, cMvTemp[iRefList [iRefIdxTemp], uiBitsTemp, uiCostTemp ); } #else ... , to bypass the L1 search we need this: #if GPB_SIMPLE_UNI if ( pcCU->getSlice()->getSPS()->getUseLDC() ) { ... } else { if ( iRefList && pcCU->getSlice()->getNoBackPredFlag() ) { uiCostTemp = MAX_UINT; //maybe not necessary cMvTemp[1][iRefIdxTemp] = cMvTemp[0][iRefIdxTemp]; } else xMotionEstimation ( pcCU, pcOrgYuv, iPartIdx, eRefPicList, &cMvPred[iRefList][iRefIdxTemp], iRefIdxTemp, cMvTemp[iRefList [iRefIdxTemp], uiBitsTemp, uiCostTemp ); } #else ... 2. I also removed the check for LD when setting the first reference list for the bidirectional search. So at two places (within #if MS_NO_BACK_PRED_IN_B0) instead of: if (pcCU->getSlice()->getSPS()->getUseLDC() && m_pcEncCfg->getUseFastEnc() && pcCU->getSlice()->getNoBackPredFlag() ) , I have: if (m_pcEncCfg->getUseFastEnc() && pcCU->getSlice()->getNoBackPredFlag() ) My understanding is that the results are slightly different now because the L1 MV is searched for in the bidirectional part of the ME, and not during the unidirectional one as before. Without fix we have: L0 search -> L0 MV L1 search -> L1 MV Init BI MV with L0 MV and L1 MV Refine L0 MV for BI An now we have: L0 search -> L0 MV Init L1 MV with L0 MV Init BI MV with L0 MV and L1 MV Refine L1 MV for BI" nsprljan 116 Unnecessary testing of MVs HM enhancement closed 2010-12-20T20:59:13+01:00 2010-12-20T21:00:28+01:00 "As reported by Woo-Jin: After looking at the code, we found that the code was designed to check other motion vector candidates inside the ME function using m_cMvFieldA, m_cMvFieldB and m_cMvFieldC to enlarge the possibility to find the best MV, which came from the JSVM code. However, in the current HM code, m_cMvFieldA, m_cMvFieldB and m_cMvFieldC were not initialized at all, which results in setting all variables to be equal to zero motion vector. Here is the related code segment you indicated: In TEncSearch::xTZSearch: // test whether one of PRED_A, PRED_B, PRED_C MV is better start point than Median predictor if ( bTestOtherPredictedMV ) { for ( UInt index = 0; index < 3; index++ ) { TComMv cMv = m_acMvPredictors[index]; pcCU->clipMv( cMv ); cMv >>= 2; xTZSearchHelp( pcPatternKey, cStruct, cMv.getHor(), cMv.getVer(), 0, 0 ); } } In the above code, m_acMvPredictors were initialized by m_cMvFieldA, m_cMvFieldB and m_cMvFieldC, however, those variables were not initialized thus they are equal to the zero vector. Since the zero-vector testing is done again just after the above code segment, I think that the above code is not needed. (Or it can be initialized correctly to use the actual motion vector candidates used in the AMVP, but the difference seems negligible from quick testing) I prefer simply to delete the above code or set bTestOtherPredictedMV to be zero as: From ""const Bool bTestOtherPredictedMV = 1"" to ""const Bool bTestOtherPredictedMV = 0"" The above change should reduce the encoding time as you indicated. " fbossen 132 Unconventional PSNR definition HM enhancement closed 2011-03-01T02:08:01+01:00 2011-03-01T22:47:23+01:00 "The current implementation in HM2.0, calculates a fidelity measure and calls it PSNR, while it is not! By definition PSNR is calculated as : 10*log10((1<> (m_uiMaxCUDepth-1)))!=0, ""Frame width should be multiple of double size of minimum CU size""); xConfirmPara( (m_iSourceHeight % (m_uiMaxCUHeight >> (m_uiMaxCUDepth-1)))!=0, ""Frame height should be multiple of double size of minimum CU size""); should be replaced with xConfirmPara( (m_iSourceWidth % (m_uiMaxCUWidth >> (m_uiMaxCUDepth-1)))!=0, ""Frame width should be multiple of minimum CU size""); xConfirmPara( (m_iSourceHeight % (m_uiMaxCUHeight >> (m_uiMaxCUDepth-1)))!=0, ""Frame height should be multiple of minimum CU size""); The current TMuC codec core allows input image sizes of odd multiple of minimum CU size and the TMuC document also does." hao@… 47 #define HHI_INTERP_FILTER_KERNEL_FIX under #if HHI_AIS HM defect closed 2010-08-16T12:22:33+02:00 2010-08-16T19:12:55+02:00 "In TypeDef.h the MOMS related define: #define HHI_INTERP_FILTER_KERNEL_FIX (l.71) is placed in the #if HHI_AIS (l.65) block. Solution: The #endif (l.73) should be moved to line 69" benjamin.bross@… 135 AlfCtrlFlag Ctx model uses the skip flag initialization HM defect closed 2011-03-22T19:08:39+01:00 2011-03-22T19:11:42+01:00 "Fix: For m_cCUAlfCtrlFlagSCModel.initBuffer ( eSliceType, iQp, (Short*)INIT_SKIP_FLAG ); a new initialization like INIT_ALFCTRL_FLAG should be added with the same 50/50 initializing as for the skip flag." bbross 140 Compiler warning in TVideoIOBitsStartCode::getFileLocation() HM defect closed 2011-04-06T10:52:09+02:00 2011-04-15T12:31:21+02:00 "Data type of return value of std::fstream::tellg() is not ""long"" but ""std::streampos"". Their sizes may be different depending on compilers. At least 64-bit compiler of MS Visual C++ 2008 in 32-bit Windows gives warning about implicit data type conversion from std::streampos to long. Although it is practically harmless for the current standardization activity, it violates HEVC software guidelines. Revised code to fix this issue is shown below. (Line number is based on HM-2.2) Line 89-90 in TVideoIOBits.h: '''streampos''' getFileLocation () { return m_cHandle.tellg(); } Void setFileLocation ('''streampos''' uiLocation) { m_cHandle.seekg(uiLocation); } Line 114 in TAppDecTop.cpp: '''streampos''' lLocation = m_cTVideoIOBitstreamFile.getFileLocation(); " hao 171 Redundant code in xRecurIntraCodingQT HM enhancement closed 2011-05-24T10:53:00+02:00 2011-05-30T01:01:42+02:00 "In TEncSearch.cpp in function xRecurIntraCodingQT() l.1369ff: {{{ } if( bCheckSplit ) { }}} can be removed because of {{{ if( bCheckSplit ) { }}} in l.1292" bbross 1523 Wrong update of prevTid0Pic HM defect new 2025-12-08T11:23:11+01:00 2025-12-08T11:28:53+01:00 "There is wrong update of POC in Void TDecTop::xCreateLostPicture(Int iLostPoc) line 370 of TDecTop.cpp caling xUpdatePreviousTid0POC. When missing frame is after first POC MSB cycle, and that missing frame is coded as a LT reference with syntax delta_poc_msb_present_flag[i] == 0 and and used_by_curr_pic_lt_flag[i] == 1, the lost pic handling routine sets the POC of the missing pic by POC LSB only and full POC correct recovering is not possible in that case. Nevertheless, that is not the problem by itself and does not make the bitstream non-compliant with spec, but lost pic copying routine erroneously updates the common value of prevTid0Pic which is used for next POC derivation. According to spec, prevTidOPic should be a value for the pic in decoding order, not for the lost pic. The bug appears as POC number going crazy after first POC MSB cycle provided there is a referenced but lost pic in DPB. N.Shlyakhov _at_ ieee -dot- org " kolya 1496 Compiling error with SEI.cpp HM defect closed 2018-08-22T15:18:54+02:00 2018-09-04T19:42:42+02:00 "Have got errors when compiling the encoder (release x64) using VC2010 and Linux. The error seems with SEI.cpp, reporting like below: .\..\source\Lib\TLibCommon\SEI.cpp(107): error C2661: 'std::vector<_Ty>::vector' : no overloaded function takes 7 arguments 1> with 1> [ 1> _Ty=SEI::PayloadType 1> ]" zhangaaron 1438 HM-16.7 compression issue HM defect closed 2016-02-09T01:43:54+01:00 2016-02-09T11:40:47+01:00 "There is my logs after testing BQSquare as an anchor with a command line -c cfg/encoder_randomaccess_main.cfg -c cfg/per-sequence/BQSquare.cfg If a refer to HM-15.0 anchor result on ftp://ftp.kw.bbc.co.uk/hevc/hm-15.0-anchors/cross-check/; I get the BD-rate loss ~12%. Is there anything I am doing wrong?" kolya 1493 I cant encode with HEVC reference software HM defect closed 2018-07-11T16:46:06+02:00 2018-07-13T17:50:21+02:00 "I'm trying to encode yuv video (1080p , Bit depth:8 bit ,Frame Rate: 120 fps (progressive) ) im using HM-16.18+SCM-8.7 , this is my code in f.cfg file : InputFile : Jockey_1920x1080_120fps_420_8bit_YUV.yuv InputBitDepth: 8 FrameRate : 120 FrameSkip : 0 SourceWidth : 1920 SourceHeight : 1080 FramesToBeEncoded : 1 I'm using this command in CMD : TAppEncoder.exe -c encoder_intra_main.cfg -c f.cfg when I open the output file I get a green screen https://i.stack.imgur.com/Vkhif.png " rocker 1506 film grain SEI encoder use wrong bits to signal num_model_values_minus1 HM defect closed 2020-04-08T01:22:57+02:00 2020-06-23T23:10:58+02:00 "The syntax element `num_model_values_minus1` should be signaled with 3 bits according to spec. The encoder SEI function `xWriteSEIFilmGrainCharacteristics`() mistakenly uses 8 bits. The decoder parsing is correct. A merge request is provided: https://vcgit.hhi.fraunhofer.de/jct-vc/HM/-/merge_requests/32" taoranlu 1516 Typo in writing ContentColourVolume SEI HM defect new 2022-06-15T20:28:56+02:00 2022-06-15T20:28:56+02:00 "Elements ""ccv_max_luminance_value"" and ""ccv_avg_luminance_value"", when writing ContentColourVolume SEI message (SEIWriter::xWriteSEIContentColourVolume), depend on m_ccvMinLuminanceValuePresentFlag, but needed to depend on m_ccvMaxLuminanceValuePresentFlag and m_ccvAvgLuminanceValuePresentFlag respectively." taoranlu 1518 windows build of HM crashes during encoding HM defect new 2022-08-31T21:43:31+02:00 2022-08-31T21:43:31+02:00 "HM16.25 encoding crashes at the beginning of coding the 1st frame when using the binary complied on windows x64 platform by cmake with visual studio 2015 (solution file generated by cmake .. -G ""Visual Studio 14 2015 Win64""). Crash can be observed by example command: >> TAppEncoder.exe -c encoder_randomaccess_main10.cfg -c RaceHorses.cfg Linux compiling and running do not have the issue." taoranlu