ticket summary component version milestone type owner status created _changetime _description _reporter 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 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 1513 TAppEncoder crashing bug HM SCC v5 (02/2018) defect new 2021-08-15T17:18:22+02:00 2021-08-15T17:18:22+02:00 "I found a bug which will cause the encoder application crash in HM-16.12+SCM-8.3. And I also checked the source codes in the highest version HM-16.20+SCM-8.8, This bug also exists in it. The bug is : a variable names '''m_uiNumBV16s''' is not initialized in the function '''TEncSearch::init''' in the file '''TEncSearch.cpp''', which will cause an invalid address accessing in function '''TEncSearch::xIntraPatternSearch''', see below source codes, thereby case the application crash issue. Void TEncSearch::xIntraPatternSearch(...) { ... else if (iRoiWidth+iRoiHeight==16) { m_uiNumBVs = m_uiNumBV16s; } ... } And we can initialize it to 0 in the function '''TEncSearch::init''' to fix it. Void TEncSearch::init(...) { ... m_uiNumBV16s = 0; ... }" AllenWang 1512 Missing NAL Header in H265 Encoder output Encoder Description v5 (02/2018) technical change new 2020-11-16T11:44:19+01:00 2020-11-16T11:44:19+01:00 "I simulated the h265enc_v2.0 with a yuv file and got the encoded output in the file 'w_bit_stream.dat' but it does have NAL Header in it. It only have the video file information.In which module NAL Header is generated? If it is known,I can print the NAL Header information and verify my results" sandeep22 1523 Wrong update of prevTid0Pic HM HM-next 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 1461 Decoder need to check if the DPB is overflowed HM SCC SCC-7.0 (HM16.8) defect yaohualibin@… assigned 2016-12-08T03:05:49+01:00 2016-12-15T00:02:51+01:00 "In HEVC SCC, in case that the DPB size is N and two versions of current pictures are different, there should be at most N-2 temporal reference pictures. When two versions of current pictures are the same (loop filters are off), there should be at most N-1 temporal reference pictures. In SCM software, the removal of unnecessary pictures in the DPB is done after current picture is decoded and after the extra version of current picture (as reference picture) is removed. If the encoder has assigned N-1 temporal reference pictures to current picture, while two versions of current pictures are different, the decoder can still decode such an illegal bitstream. In the provided patch, an assertion is made such that after removing unnecessary pictures from the DPB for current picture (and after decoding current picture), the DPB fullness including the current decoded picture itself should be at most N - TwoVersionsCurrDecPicFlag." xiaozhongxu0000 1472 Diff between specification and HM on palette coding HM SCC defect new 2017-05-04T16:49:36+02:00 2017-05-04T16:49:36+02:00 "In the last specification, palette_coding() is specified as below: {{{ palette_coding( x0, y0, nCbS ) { ... PaletteRun = nCbS * nCbS − PaletteScanPos − 1 ... if( MaxPaletteIndex > 0 ) { if ( CopyAboveIndicesFlag[ xC ][ yC ] == 0 ) remainingNumIndices − = 1 PaletteMaxRun = nCbS * nCbS − PaletteScanPos − 1 − remainingNumIndices − copy_above_indices_for_final_run_flag if( remainingNumIndices > 0 || CopyAboveIndicesFlag[ xC ][ yC ] != copy_above_indices_for_final_run_flag ) if( PaletteMaxRun > 0 ) { palette_run_prefix if( ( palette_run_prefix > 1 ) && ( PaletteMaxRun != ( 1 << ( palette_run_prefix − 1 ) ) ) ) palette_run_suffix } } ... } }}} When PaletteMaxRun is equal to 0, no palette_run_prefix is parsed. There is no inference rule for this syntax element. In this case, PaletteRun is not derived from palette_run_prefix and palette_run_suffix. It is set to default value: nCbS * nCbS − PaletteScanPos − 1; as specified above in the parsing. However, it seems that PaletteRun should be set to 0 according to the semantic of PaletteMaxRun (7.4.9.13 Palette semantics: ""The variable PaletteMaxRun represents the maximum possible value for PaletteRun""). In the HM, PaletteRun is set to 0 in this case. What is the right value for PaletteRun when PaletteMaxRun is equal to 0: - nCbS * nCbS − PaletteScanPos − 1 or - 0 ? In the same idea, the variable PaletteMaxRun is derived before checking the following condition: {{{ remainingNumIndices > 0 || CopyAboveIndicesFlag[ xC ][ yC ] != copy_above_indices_for_final_run_flag }}} However, when this condition is not verified, the variable PaletteMaxRun is not used and could violate the condition: (7.4.9.13) ""It is a requirement of bitstream conformance that the value of PaletteMaxRun shall be greater than or equal to 0."" Indeed, it is possible to have PaletteMaxRun equal to -1 when these 3 conditions are filled: - PaletteScanPos = (nCbs * nCbs) - 1 - remainingNumIndices = 0 - copy_above_indices_for_final_run_flag = 1 This case appears especially in HM generated streams. Is this case a legitimate one ? If, as I believe, it is, this constraint needs to be verified after the condition. The easiest way to do this is to move PaletteMaxRun derivation after the condition, as following: {{{ palette_coding( x0, y0, nCbS ) { ... PaletteRun = nCbS * nCbS − PaletteScanPos − 1 ... if( MaxPaletteIndex > 0 ) { if ( CopyAboveIndicesFlag[ xC ][ yC ] == 0 ) remainingNumIndices − = 1 if( remainingNumIndices > 0 || CopyAboveIndicesFlag[ xC ][ yC ] != copy_above_indices_for_final_run_flag ) { PaletteMaxRun = nCbS * nCbS − PaletteScanPos − 1 − remainingNumIndices − copy_above_indices_for_final_run_flag if( PaletteMaxRun > 0 ) { palette_run_prefix if( ( palette_run_prefix > 1 ) && ( PaletteMaxRun != ( 1 << ( palette_run_prefix − 1 ) ) ) ) palette_run_suffix } } } ... } }}}" forayr 1484 HM crashes when a NALU with zero payload size HM SCC defect new 2017-12-05T19:24:06+01:00 2018-01-08T19:50:38+01:00 "Spec allows to have NALU with zero payload size. But HM crashes when NALU has a zero payload size. SEIread.cpp --> Void SEIReader::xReadSEImessage Need to add a condition if (!payloadSize) return;" swong10 1485 HM cannot handle multiple appearance of current frame in the reference list HM SCC defect new 2017-12-05T19:33:17+01:00 2018-01-08T19:51:35+01:00 "Spec allows current frame to be added in the reference list multiple times when IBC is used. But HM code cannot handle it. The code exit when the very first appearance is found. HM Decoder 16.15_SCM8.4 TDecTop.cpp --> Void TDecTop::markCurrentPictureAfterILFforShortTermRef(), need to remove the ""return"" as follows: if ( pcPic->getCurrentPicFlag() == true ) { pcPic->setIsLongTerm( false ); pcPic->getSlice( 0 )->setReferenced( true ); pcPic->setCurrentPicFlag( false ); //last time to use the current picture flag } TDecTop.cpp --> Void TDecTop::updateCurrentPictureFlag(), need to add the following ""return"" if ( pcPic->getCurrentPicFlag() == true ) { pcPic->setCurrentPicFlag( false ); //last time to use the current picture flag return; } " swong10 1486 Incorrect warning message HM SCC defect new 2017-12-05T19:44:20+01:00 2018-01-08T19:52:17+01:00 " Spec allows IBC MV to cross the dependent slice boundary. But HM will generate warning message. BV check is incorrect. It should be disabled. HM Decoder/Encoder 16.15_SCM8.4 TDecCu.cpp --> Void TDecCu::xReconInter() The following modified condition should be added to the print message: #if proposed fix if (pcSym->getCtu(ctuAddr)->getSlice()->getSliceCurStartCtuTsAddr() != pcCU->getSlice()->getSliceCurStartCtuTsAddr()) #else if (pcSym->getCtu(ctuAddr)->getSlice()->getSliceIdx() != pcCU->getSlice()->getSliceIdx()) #endif { printf(""BV (%i,%i) for PU%i(%u)/%i in CU %u,%u, slice %u points to CTU %u, slice %u\n"", mvx, mvy, iPartIdx, uiPartAddr, numParts, pcCU->getCtuRsAddr(), pcCU->getZorderIdxInCtu(), pcCU->getSlice()->getSliceIdx(), ctuAddr, pcSym->getCtu(ctuAddr)->getSlice()->getSliceIdx()); } " swong10 1487 Last decoded frame is not being outputted correctly HM SCC defect new 2017-12-05T19:57:09+01:00 2018-01-08T19:52:51+01:00 " The decoder should output the last decoded frame when the bitstream has reached its end. It happens when the display order and decoding order is different. Need to update the loop filter flag to correct the situation. HM Decoder/Encoder 16.15_SCM8.4 TAppDecTop.cpp --> Void TAppDecTop::decode() The following update to the loopFiltered is needed to correct else if ( (bNewPicture || !bitstreamFile || nalu.m_nalUnitType == NAL_UNIT_EOS ) && m_cTDecTop.getFirstSliceInSequence () ) { m_cTDecTop.setFirstSliceInPicture (true); loopFiltered = (nalu.m_nalUnitType == NAL_UNIT_EOS); }" swong10 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 1508 Shift-warnings with 64bit version of HM16.21 with high-bitdepth support when compiling with VS2019 HM RExt defect new 2020-06-20T18:09:51+02:00 2020-06-20T18:09:51+02:00 "The following warnings were issued, which prevented due to the by default set /WX flag compilation. Utilities.vcxproj -> ...\HM-HM-16.21_16bit\lib\vs16\msvc-19.24\x86_64\release\Utilities.lib ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(1364,58): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(1364,58): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(1401,58): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(2041,53): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(3417,63): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(3443,63): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(1401,58): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(2041,53): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(3417,63): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) ...\HM-HM-16.21_16bit\source\Lib\TLibCommon\TComTrQuant.cpp(3443,63): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) TLibCommonAnalyser.vcxproj -> ...\HM-HM-16.21_16bit\lib\vs16\msvc-19.24\x86_64\release\TLibCommonAnalyser.lib It always seems to be the same issue, but it is unclear if it should be indeed a 32bit or 64bit shift in this moment." iejahPaevei8Gi 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 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 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 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 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 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 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 1437 typo in the spec in 8.4.4.3 SCC text defect new 2016-02-03T03:15:54+01:00 2020-06-24T23:45:57+02:00 "In draft 8.4.4.3: Inputs to this process are: ... – an array resSampleArrayCr specifying the luma residual samples of the current block. In the sentence above , luma should be chroma " yejiangli 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 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 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 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 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 1478 HM 16.15_SCM8.4 producing streams with incorrect PPS ID for some slices HM SCC SCC-7.0 (HM16.8) defect new 2017-08-16T14:25:43+02:00 2017-08-22T03:16:07+02:00 "I generated a stream using the attached Cfg file. I am also attaching the generated stream. In the AU no 17 having POC 32 the PPS ID encoded in the first slice is different from the PPS ID encoded in the other slices.HM considers them to be the same AU, but this should not be the case.The issue seems to be in both encoder and decoder." sunnythakur 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 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 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 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 1511 decoder failed when two PPSs are coded and IBC is disabled in one PPS and enabled in another one HM SCC SCC-7.0 (HM16.8) defect new 2020-11-02T20:50:43+01:00 2020-11-02T22:21:19+01:00 The decoder has mismatches for the following case: two PPSs are signalled in the bitstream, pps_curr_pic_ref_enabled_flag are set to false and true in the first and second PPS, respectively, and the first few frames are coded referring to the first PPS and remaining frames are coded referring to the second PPS. In the current SCM, when a frame referring to the second PPS starts to be decoded(the variable m_pcTwoVersionsOfCurrDecPicFlag is set from false to true), the reconstructed frame before loop filtering(e.g. deblocking/SAO) should be removed after decoding the current frame. However, in the current SCM, a frame is removed when the m_bCurPic flag and the m_bIsLongTerm flag are true and false respectively. When the decoder performs the removal, the first frame in the current picture list, a frame decoded referring to the first SPS, will be undesirably removed instead of the current picture before being filtered, which results in errors on constructing the reference frame list when decoding of the successive frames. And, the encoder works well. Weijia 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 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 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 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 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 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 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 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 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 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 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 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 1300 Conflict in Lambda calculation when SATD is enabled. Encoder Description ED4 (F802) d0 defect new 2014-07-02T08:51:13+02:00 2014-07-02T08:51:13+02:00 "According to Encoder description doc(JCTVC-Q1002) section 4.1.4.1 Lagrangian constant values, lambda used for RD cost calculation is multiplied by 0.95 when SATD is used. But in HM encoder code (HM14.0) I find following condition(FILE : TEncSlice.cpp, Function : initEncSlice() , Line No : 351) if ( !m_pcCfg->getUseHADME() && rpcSlice->getSliceType( ) != I_SLICE ) { dLambda *= 0.95; } This suggest that, 0.95 is multiplied when (m_bUseHADME== 0) which is conflicting with the document. " prashanthns 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 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 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 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 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 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 1367 Additional decoder verification checks for non-conforming streams HM HM-16.2 enhancement new 2015-02-02T17:41:56+01:00 2015-02-02T17:41:57+01:00 "The decoder does not currently verify that the bitstream conforms to the standard. Various checks have previously been requested for the verification of some syntax elements: #1360 sps.separate_colour_plane_flag #1313 sps.intra_smoothing_disabled_flag #1227 vps/sps.num_reorder_pics. Potentially in the future the decoder could be instructed to verify that the bitstream conforms, and either aborts, or reports problems. Please attach other such requests to this bug report (though please do not include RExt SPS/PPS entries as these are related to #1313) " karlsharman 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 1514 Problems with HM Software Manual HM HM-16.14 HM+SCC-8.0 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 1475 Difference between HM and spec. on green metadata SEI HM HM-16.14 HM-16.15 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 1466 SEIs for skipped pictures assigned to non-skipped picture HM HM-16.14 HM-next 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 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 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