__group__ ticket summary component version type owner status created _changetime _description _reporter 311 "missing definition of ""cu_qp_delta_enabled_flag"" in the lateset WD, JCTVC-G1103_d9" Text defect bbross closed 2012-02-05T23:15:32+01:00 2012-02-05T23:29:09+01:00 "Dear Benjamin, The definition of variable ""cu_qp_delta_enabled_flag"" in the syntax table is missing in the latest version of WD, i.e. JCTVC-G1103_d9. Please fix it. Thanks Best Regards Haoping" haoping 1359 Pic Timing: cpb removal delay calculation causes conformance failures Text defect closed 2014-12-13T07:01:43+01:00 2015-01-15T00:55:50+01:00 "As I understand it, calculating CPB removal times can have this example path below (HM & x265 have this behavior), which can force non-conformance. Am I understanding these derivations correctly? What does au_cpb_removal_delay mean for the AU containing a BP message? --- AU-0 Buffering Period: concatenation_flag = 0 nal_initial_cpb_removal_delay = 32401 Pic Timing: au_cpb_removal_delay_minus1 = 0 AuCpbRemovalDelayVal = au_cpb_removal_delay_minus1 + 1 (D-2) = 1 AuNominalRemovalTime[0] = InitCpbRemovalDelay[0] ÷ 90000 (C-10) = 0.36001 AuCpbRemovalTime[0] = AuNominalRemovalTime[0] = 0.36001 AU-1 Pic Timing: au_cpb_removal_delay_minus1 = 0 AuCpbRemovalDelayVal = 1 * Violates: ""Within one buffering period, the AuCpbRemovalDelayVal values for any two access units shall not be the same."" AuNominalRemovalTime[1] = AuNominalRemovalTime[0] + ClockTick * (AuCpbRemovalDelayVal - CpbDelayOffset) (C-12) = 0.36001 + 0.04171 * (1-0) = 0.40172 AuCpbRemovalTime[1] = AuNominalRemovalTime[1] AU-2 Pic Timing: au_cpb_removal_delay_minus1 = 1 AuCpbRemovalDelayVal = 2 AuNominalRemovalTime(2) = AuCpbRemovalTime[2] = 0.44343 AU-3 Buffering Period: concatenation_flag = 0 nal_initial_cpb_removal_delay = 36001 Pic Timing: au_cpb_removal_delay_minus1 = 0 AuCpbRemovalDelayVal = 1 AuNominalRemovalTime(3) = baseTime + ClockTick * ( tmpCpbRemovalDelay - CpbDelayOffset ) = 0.40172 (same as AU-1) AuCpbRemovalTime[3] = AuNominalRemovalTime[3] * This breaks the timeline between buffering periods. First instinct is to make have this au_cpb_removal_delay_minus1 encoded as the previous' plus one. But, that would surely cause a duplicate. * Given AuNominalRemovalTime[3] - AuCpbRemovalTime[2] < 0, Clause A.4.2.a is forced to fail. AU-4 Pic Timing: au_cpb_removal_delay_minus1 = 0 AuCpbRemovalDelayVal = 1 * Violates: ""Within one buffering period, the AuCpbRemovalDelayVal values for any two access units shall not be the same."" AuNominalRemovalTime(4) = 0.40172 * Given AuCpbRemovalTime[4] - AuCpbRemovalTime[3] == 0, Clause A.4.2.d is forced to fail. --- " abishop 304 in the AMVP list derivation the scaled MVP can overwrite non-scaled MVP on top when the left side is mepty Text defect bbross closed 2012-02-03T02:01:09+01:00 2012-02-16T07:34:55+01:00 " Solution: 8.4.2.1.7 Derivation process for motion vector predictor candidates Replace 4. When isScaledFlagLX is equal to 0, availableFlagLXB is set equal to 0 and for ( xBk, yBk ) from ( xB0, yB0 ) to ( xB2, yB2 ) where xB0 = xP +nPSW, xB1 = xB0 - MinPuSize , and xB2 = xP - MinPuSize, the following applies repeatedly until availableFlagLXB is equal to 1: With 4. When isScaledFlagLX is equal to 0 and availableFlagLXB is equal to 1, mvLXA is set equal to mvLXB and refIdxA is set equal to refIdxB and availableFlagLXA is set equal to 1. 5. When isScaledFlagLX is equal to 0, availableFlagLXB is set equal to 0 and for ( xBk, yBk ) from ( xB0, yB0 ) to ( xB2, yB2 ) where xB0 = xP +nPSW, xB1 = xB0 - MinPuSize , and xB2 = xP - MinPuSize, the following applies repeatedly until availableFlagLXB is equal to 1: " zhou 308 Typo in SAO syntax Text defect bbross closed 2012-02-05T02:58:10+01:00 2012-02-07T04:56:01+01:00 "Section 7.3.3.4 Sample adaptive offset parameter syntax The present text says this: ********************** sao_flag_cb if( sao_flag_cb ) { sao_split_param( 0, 0, 0, 1 ) sao_split_param( 0, 0, 0, 1 ) } sao_flag_cr if( sao_flag_cr ) { sao_split_param( 0, 0, 0, 2 ) sao_split_param( 0, 0, 0, 2 ) } ********************** The 'sao_split_param' line is repeated twice in each of the two 'if' clauses. The second line should be 'sao_split_offset(...)' in both cases. " hellman 323 incomplete integration of the provided WD text to JCTVC-H1003_d0 on signaling intra chroma prediction mode Text defect bbross closed 2012-02-11T09:34:15+01:00 2012-02-16T07:40:59+01:00 For the adopted intra chroma mode signling method from H0475/H0326, no context is used when parsing the two FL binarized bins of intra_chroma_pred_mode according to the provided WD text. But this change is missing in the d0 version of WD6 in H1003. hyang 415 Meeting information for HEVC text spec draft 6 (WD: doc# H1003 dk) incorrect Text defect bbross closed 2012-03-18T00:01:33+01:00 2012-04-02T14:01:14+02:00 In draft K of the text specification the meeting information is from the 7th meeting (Geneva), but document JCTVC-H1003 is from the San Jose meeting. rkaliski 1005 Extra hypen after equation (8-26) Text defect bbross closed 2013-02-08T22:26:12+01:00 2013-02-19T20:54:24+01:00 "An extra hyphen was found before text between equation (8-26) and equation (8-27) in JCTVC-L1003_v11: – – The current luma location ( xBY, yBY ) and the neighbouring luma location ( xNY, yNY ) are derived as follows." auyeung 1008 uniform_spacing_flag should be inferrable Text defect bbross closed 2013-02-14T13:33:20+01:00 2013-02-19T20:54:59+01:00 "I propose to add wording: ""When not present, the value of uniform_spacing_flag is inferred to be equal to 1"". to ""uniform_spacing_flag"" semantic description, otherwise scanning process defined by: 6.5.1 Coding tree block raster and tile scanning conversion process is not well defined. 7.4.2.3 Picture parameter set RBSP semantics uniform_spacing_flag equal to 1 specifies that tile column boundaries and likewise tile row boundaries are distributed uniformly across the picture. uniform_spacing_flag equal to 0 specifies that tile column boundaries and likewise tile row boundaries are not distributed uniformly across the picture but signalled explicitly using the syntax elements column_width_minus1[ i ] and row_height_minus1[ i ]. When not present, the value of uniform_spacing_flag is inferred to be equal to 1. Wlodzimierz" vlad 1009 diff_cu_qp_delta_depth should be inferrable Text defect bbross closed 2013-02-14T13:41:46+01:00 2013-02-19T20:55:28+01:00 "I propose to add wording: ""When not present, the value of diff_cu_qp_delta_depth is inferred to be equal to 0."" to ""diff_cu_qp_delta_depth"" semantic description, otherwise variable: Log2MinCuQpDeltaSize = Log2CtbSizeY − diff_cu_qp_delta_depth is not well defined. ""diff_cu_qp_delta_depth specifies the granularity for QP Y values within a picture. The value of diff_cu_qp_delta_depth shall be in the range of 0 to log2_diff_max_min_luma_coding_block_size, inclusive. When not present, the value of diff_cu_qp_delta_depth is inferred to be equal to 0."" Wlodzimierz." vlad 1045 Inconsistent tile definition with CTB and CTU Text defect closed 2013-03-14T19:44:55+01:00 2013-03-15T17:23:12+01:00 "In D10 ver 25: 3.153 tile: A rectangular region of coding tree blocks within the same tile column and tile row in a picture. In section 6.3, ""tile is a sequence of coding tree units"" " auyeung 1058 Minor issue with the definition of offsetSign in the SAO semantics section (7.4.9.3) Text defect closed 2013-04-01T20:16:09+02:00 2014-01-27T18:44:59+01:00 "In the current specification (JCTVC-L1003_v34) in section 7.4.9.3, in the semantics of sao_offset_sign, a temporary variable, named offsetSign is defined that specifies the sign for each SAO class. Given the relationship of offsetSign with class index ''i'', and of offsetSign later being used in equation 7-58 where offsetSign should vary within the for loop according to the value of ''i'', it seems more appropriate to maybe, instead of defining a single variable, to define offsetSign as an array. As it is, it seems that maybe equation 7.58 could be misinterpreted. Maybe also an alternative, instead of using offsetSign could be to use an equation of the form: ============ SaoOffsetVal[ cIdx ][ rx ][ ry ][ 0 ] = 0 for( i = 0; i < 4; i++ ) SaoOffsetVal[ cIdx ][ rx ][ ry ][ i + 1 ] = (1 - 2 * sao_offset_sign[ cIdx ][ rx ][ ry ][ i ] ) * sao_offset_abs[ cIdx ][ rx ][ ry ][ i ] << ( bitDepth − Min( bitDepth, 10 ) ) ============ and alter the semantics of sao_offset_sign so as it is appropriate initialized/set for all SAO categories, i.e.: ============== If SaoTypeIdx[ cIdx ][ rx ][ ry ] then, sao_offset_sign[ cIdx ][ rx ][ ry ][ 0 ] = sao_offset_sign[ cIdx ][ rx ][ ry ][ 1 ] = 0 sao_offset_sign[ cIdx ][ rx ][ ry ][ 1 ] = sao_offset_sign[ cIdx ][ rx ][ ry ][ 3 ] = 1 otherwise – If sao_merge_left_flag is equal to 1, sao_offset_sign[ cIdx ][ rx ][ ry ][ i ] is inferred to be equal to sao_offset_sign[ cIdx ][ rx − 1 ][ ry ][ i ]. – Otherwise, if sao_merge_up_flag is equal to 1, sao_offset_sign[ cIdx ][ rx ][ ry ][ i ] is inferred to be equal to sao_offset_sign[ cIdx ][ rx ][ ry − 1 ][ i ]. – Otherwise, sao_offset_sign[ cIdx ][ rx ][ ry ][ i ] is inferred to be equal 0. =============== Kind regards, Alexis" alexis 1187 Bitstream conformance problem for IRAP pictures in HEVC version 1 Text defect closed 2013-10-25T10:02:24+02:00 2014-01-27T18:49:19+01:00 "In C.4 one of the conditions for bitstream conformance states: ""8. For each current picture, the value of maxPicOrderCnt − minPicOrderCnt shall be less than MaxPicOrderCntLsb / 2."" Shouldn't it rather be: ""8. For each current picture that is not an IRAP picture with NoRaslOutputFlag equal to 1, the value of maxPicOrderCnt − minPicOrderCnt shall be less than MaxPicOrderCntLsb / 2."" Both the current picture and 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, are included in the set of pictures from which maxPicOrderCnt and minPicOrderCnt are calulated. IRAP picture with NoRaslOutputFlag equal to 1 has POC msb equal to 0 which makes it difficult to fulfill the above condition. " jonatan 1316 C.2.2: minor editing issue Text defect closed 2014-08-26T17:41:22+02:00 2018-01-22T06:17:13+01:00 "It seems the word ""in"" should be removed twice in the following paragraphs at the beginning of section C.2.2 (see strike through) If SubPicHrdFlag is equal to 0, the variable subPicParamsFlag is set equal to 0, and the process ~~in~~ specified in the remainder of this subclause is invoked with a decoding unit being considered as an access unit, for derivation of the initial and final CPB arrival times for access unit n. Otherwise (SubPicHrdFlag is equal to 1), the process ~~in~~ specified in the remainder of this subclause is first invoked with the variable subPicParamsFlag set equal to 0 and a decoding unit being considered as an access unit, for derivation of the initial and final CPB arrival times for access unit n, and then invoked with subPicParamsFlag set equal to 1 and a decoding unit being considered as a subset of an access unit, for derivation of the initial and final CPB arrival times for the decoding units in access unit n. (exists in JCTVC-R1013_v4)" ksuehring 1370 Annex G indexed as Annex F Text defect closed 2015-02-03T14:24:02+01:00 2015-02-03T17:48:17+01:00 "in JCTVC-R1013_v6 document annex G sections are marked with ""F"" letter " kolya 1386 typo in spec Text defect closed 2015-04-03T16:08:39+02:00 2018-01-22T06:26:29+01:00 "There is around (7-76) equation in the JCTVC-R1013_v6 last_sig_coeff_x_prefix specifies the prefix of the column position of the last significant coefficient in scanning order within a transform block. The values of last_sig_coeff_x_prefix shall be in the range of 0 to ( log2TrafoSize << 1 ) − 1, inclusive. last_sig_coeff_y_prefix specifies the prefix of the row position of the last significant coefficient in scanning order within a transform block. The values of last_sig_coeff_y_prefix shall be in the range of 0 to ( log2TrafoSize << 1 ) − 1, inclusive. it looks like ( 1 << log2TrafoSize ) − 1 should be there " kolya 1395 collocated_ref_idx inference seems missing Text defect closed 2015-05-16T00:04:21+02:00 2018-01-22T06:28:29+01:00 collocated_ref_idx is not signalled when number of reference pictures is 1, but its value is used in collocated picture derivation. Inference to 0 when not present seems necessary in the semantics. Vadim D10 (L1003) v1 698 "Definition of TRAIL_R, TSA_R and STSA_R in Table 7-1, and a typo ""candiate""" Text D10 (L1003) v1 defect bbross closed 2012-08-28T10:03:12+02:00 2013-01-20T10:11:34+01:00 "In JCTVC-J1003_d7, some definition of nal_unit_type seems unclear as follows: TRAIL_R is described only in Table 7-1. TSA_R is referred 3 times, but not defined. STSA_R is referred twice, but not defined. (It seems ""_R"" represents ""reference"", but not mentioned.) Similar concern exists for TRAIL_N, TSA_N and STSA_N, but they are described (probably as non-reference) in NOTE 6 of Table 7-1. As for typo, ""candiate"" should be ""candidate"". " yamakage D10 (L1003) v1 894 RASL_NUT and RADL_NUT in definitions Text D10 (L1003) v1 defect bbross closed 2012-12-08T23:49:31+01:00 2013-01-20T10:12:42+01:00 "We believe these two ""NUTs"" are obsolete but they are still found in the ""definitions"" section. In any case, there is inconsistency between these and the RA?L_N RA?L_R values. " Parabola D10 (L1003) v1 956 Removal of start codes, if present, for bitstream conformance tests Text D10 (L1003) v1 defect bbross closed 2013-01-18T01:50:48+01:00 2013-01-20T10:12:13+01:00 "The following sentence at the end of step 3 in C.1: When BitstreamToDecode is a Type II bitstream and NalHrdModeFlag is equal to 0, all non-VLC NAL units except for filler data NAL units are discarded from BitstreamToDecode, and the remaining bitstream is assigned to BitstreamToDecode. Should be changed to When BitstreamToDecode is a Type II bitstream and NalHrdModeFlag is equal to 0, all non-VLC NAL units except filler data NAL units and all leading_zero_8bits, zero_byte, start_code_prefix_one_3bytes, and trailing_zero_8bits syntax elements, when present, are discarded from BitstreamToDecode, and the remaining bitstream is assigned to BitstreamToDecode." yk D10 (L1003) v1 957 Confusing definitions Text D10 (L1003) v1 defect bbross closed 2013-01-18T10:17:50+01:00 2013-01-20T10:13:26+01:00 "In definitions 3.15 and 3.59, there are several occurrences of statements in the form ""when a X picture has nal_unit_type equal to Y..."" Since pictures don't have nal_unit_type's, presumably this is intended to mean: ""when all slice segments in X have nal_unit_type Y"" or ""when at least one slice segment in X has nal_unit_type Y"". Additionally, it is not clear from the definition whether it is intended to allow different slice segments in X to have different nal_unit_type values." eugene.kuznetsov D10 (L1003) v1 959 Operator precedence Text D10 (L1003) v1 defect bbross closed 2013-01-18T12:15:02+01:00 2013-01-20T10:15:09+01:00 In formula 9-3, 1 << Log2CtbSizeY must be placed in parentheses, to reflect the fact that << has lower precedence than + and -. eugene.kuznetsov D10 (L1003) v1 961 1-CTB wide picture, wavefront, and dependent slices (text) Text D10 (L1003) v1 defect bbross closed 2013-01-18T17:41:57+01:00 2013-01-20T10:11:13+01:00 "Related to #943, the change in bold is proposed (still relevant in L0030-v3). This extra condition should not affect decision to WPP synchronize (availability check makes it redundant). But it does allow DS synchronization to behave as described in #943. The context variables of the arithmetic decoding engine are initialized as follows. – If the coding tree unit is the first coding tree unit in a tile, the initialization process for context variables is invoked as specified in subclause 9.2.1.1. – Otherwise if entropy_coding_sync_enabled_flag is equal to 1, **PicWidthInCtbsY is greater than 1** and CtbAddrInRS % PicWidthInCtbsY is equal to 0, the following applies" Parabola D10 (L1003) v1 970 Typo - written 'semgnet' instead of 'segment' Text D10 (L1003) v1 defect bbross closed 2013-01-22T14:02:13+01:00 2013-01-24T11:00:25+01:00 "In the section 7.4.8.1, in the description of entry_point_offset[ i ] the following sentence is present: ... shall consist of all coded bits of all coding tree units in the slice that are ... The word semgnet should be replaced with segment." shevach D10 (L1003) v1 955 In 8.5.4.1, the number of step starts 2. Text D10 (L1003) v1 defect bbross closed 2013-01-17T18:11:20+01:00 2013-01-20T10:10:50+01:00 In 8.5.4.1, the number of step starts 2. chujoh D10 (L1003) v1 964 misspelling of pictur Text D10 (L1003) v1 defect bbross closed 2013-01-19T17:56:04+01:00 2013-01-20T10:13:01+01:00 "In 7.4.8.1 ""picture"" is misspelled as ""pictur"" in the semantics description of lt_idx_sps[i]." dthoang D10 (L1003) v1 879 SAO luma vs. chroma locations Text D10 (L1003) v1 enhancement bbross closed 2012-12-02T09:19:39+01:00 2013-01-20T10:09:41+01:00 "8.7.3.2 Coding tree block modification process has to distinguish between locations within the current component (being either luma or chroma) for indexing recPicture and saoPicture, and luma locations for indexing pcm_flag and MinTbAddrZS. Currently both cases are using indexes based on xC, yC (current component). And a typo: - If one or more of the following conditions for ( xS, xS) should be changed to - If one or more of the following conditions for ( xS, yS) " stefane D10 (L1003) v1 881 slice_disable_deblocking_filter_flag in in-loop filter process Text D10 (L1003) v1 enhancement bbross closed 2012-12-02T09:55:15+01:00 2013-01-20T10:10:02+01:00 "In 8.7.1 General: 1. When slice_disable_deblocking_filter_flag is equal to 0, the following applies. a slice layer syntax element is used at picture level. Enabling / disabling deblocking should instead be specified inside 8.7.2 Deblocking filter process depending on the slice that contains the current coding unit. The current wording (any edges for which the deblocking filter process is disabled by slice_disable_deblocking_filter_flag) may be sufficient." stefane D10 (L1003) v1 883 typos and potential editorial changes in 8.7.2 Deblocking filter process Text D10 (L1003) v1 enhancement bbross closed 2012-12-02T10:44:24+01:00 2013-01-20T10:10:27+01:00 "8.7.2.1 Derivation process of transform block boundary Specify edgeFlags also as an input to the process. trafoDepth1 -> trafoDepth 8.7.2.2 Derivation process of prediction block boundary Specify edgeFlags also as an input to the process. 8.7.2.4.2 Horizontal edge filtering process for chroma: For xDk set equal to k << 2, k = 0..nD*2 − 1, the following applies. -> For xDk set equal to k << 2, k = 0..nD − 1, the following applies. 8.7.2.4.3 Decision process for luma block edges dqp -> dpq (in 3 places) 8.7.2.4.4 Filtering process for luma block edges the locations ( xC + xB +i, yC + yB + k ), ( xC + xB - i - 1, yC + yB + k ) -> the locations ( xC + xB - i - 1, yC + yB + k ), ( xC + xB +i, yC + yB + k ) (parameters are swapped; more accurate would be to explicitly assign actual to formal arguments whenever they have different names or the actual argument is an expression) for EDGE_VER: recPictureL[ xC + xB + k ][ yC + yB − i − 1 ] = pi’ (8 299) -> recPictureL[ xC + xB − i − 1 ][ yC + yB + k ] = pi’ (8 299) and recPictureL[ xC + xB + k ][ yC + yB + j ] = qj’ (8 300) -> recPictureL[ xC + xB + j ][ yC + yB + k ] = qj’ (8 300) 8.7.2.4.5 Filtering process for chroma block edges Input bS could be removed, it is always equal to 2. slice_cb_qp_offset or slice_cb_qp_offset -> slice_cb_qp_offset or slice_cr_qp_offset 8.7.2.4.6 Decision process for a luma sample i = 0..3 -> i = 0, 3 (pi and qi with i = 1, 2 are not used) 8.7.2.4.7 Filtering process for a luma sample When nDp is greater than 0 and one or more of the following conditions are true for i = 0..nDp-1, nDp is set equal to 0 -> When nDp is greater than 0 and one or more of the following conditions are true for i = 0, nDp is set equal to 0 (the conditions for i > 0 do not differ from those for i = 0). Same for nDq. " stefane D10 (L1003) v2 944 Semantics on pic_scaling_list_data_present_flag Text D10 (L1003) v2 defect bbross closed 2013-01-10T14:42:15+01:00 2013-01-24T11:00:42+01:00 "The following sentences see to contradict eachother: 1) pps_scaling_list_data_present_flag equal to 0 specifies that the scaling lists used for the pictures referring to the picture parameter set is inferred to be equal to those specified by the active sequence parameter set. 2) When scaling_list_enable_flag is equal to 1 and pps_scaling_list_data_present_flag is equal to 0, the default scaling list data is used to derive the array ScalingFactor as described in the scaling list data semantics 7.4.6. When the value is 0, should the SPS scaling list or the default scaling list be used? " fuldseth D10 (L1003) v2 1013 missing read_bits(1) when pcm_flag is decoded as 1 Text D10 (L1003) v2 defect closed 2013-02-20T11:58:36+01:00 2018-01-22T08:49:17+01:00 "The spec (9.2.3.2.4) requires that if we decode pcm_flag and it is one, no renormalization is done and a bit is read from the bitstream and it must be one. It seems that the reference software has not implemented the reading of this bit one yet when we decode value one of pcm_flag. As far as I understand, the decoding of pcm_flag is done in Void TDecSbac::parseIPCMInfo. In this function, m_pcTDecBinIf->decodeBinTrm(uiSymbol) is called to decode pcm_flag. There is no bit reading from the bitstream if pcm_flag is one in the function decodeBinTrm(uiSymbol). Then m_pcTDecBinIf->decodePCMAlignBits() is called to read bits until byte-alignment. m_pcTDecBinIf->decodePCMAlignBits() is equal to the following pseudo-code in the spec : while (!byte_aligned()) pcm_alignment_zero_bit." PhuongNguyen D10 (L1003) v2 342 inter prediction definition Text D10 (L1003) v2 defect bbross closed 2012-02-29T06:53:35+01:00 2013-03-06T16:34:18+01:00 "(actual version dK) 3.49 inter prediction: A prediction derived from only data elements (e.g. sample value or motion vector) of reference pictures other than the current decoded picture. The inter prediction may also derive motion data from spatial neighbours." libin D10 (L1003) v2 435 Terminology: Usage of 'location' vs usage of 'position'. Text D10 (L1003) v2 defect bbross closed 2012-03-23T16:20:55+01:00 2013-03-06T16:35:24+01:00 "Is there a different meaning for the terms 'location' and 'position'? They seem to be used synonymously (e.g. in 7.4.10, semantics of significant_coeff_flag[ xC ][ yC ]) " mwi D10 (L1003) v2 519 definition of bi-prediction, uni-prediction and list 0 prediction is unclear Text D10 (L1003) v2 defect bbross closed 2012-05-03T12:01:14+02:00 2013-03-06T16:37:34+01:00 """bi-prediction"" and ""uni-prediction"" are referred in 3.90, 3.91 and 3.92 for defining referece picture list 0/1 and reference picture lists combination. But they are not defined. And, it is unclear if list 0 and list 1 can be used for uni-prediction. And then, the ""list 0 prediction"" is referred in 7.3.4.7 (Weighted prediction parameters semantics), but there is no defintion on it. Revisions to be considered; 1. Need to clarify definitions of ""bi-prediction"", ""uni-prediction"" and ""list 0/1 prediction"", and 2. Need to clarify definitions of reference picture list 0/1 about the use of uni-prediction. " suzukiyos D10 (L1003) v2 685 HM8/WD mismatch for abs_mvd_greater0_flag and abs_mvd_greater1_flag ctxIdx values Text D10 (L1003) v2 defect bbross closed 2012-08-22T07:11:33+02:00 2013-02-19T21:07:24+01:00 "In HM-8.0, “198” is used for initValue of abs_mvd_greater1_flag. However, in the WD, “169” or “198” is used for initValue of abs_mvd_greater1_flag. Table 9-19 in the WD should be changed to: Initialization variable: 0, 1, 2, 3 initValue: 140, 169, 198, 198 HM-8.0 ContexTables.h line 232: {{{ static const UChar INIT_MVD[3][NUM_MV_RES_CTX]= { { 169, 198, }, { 140, 198, }, { CNU, CNU, }, }; }}}" tajime D10 (L1003) v2 707 entropy_coding_sync_enabled_flag and tiles_enabled_flag issue Text D10 (L1003) v2 defect bbross closed 2012-08-30T14:30:12+02:00 2013-03-06T16:46:32+01:00 "The main profile restricts that "" tiles_enabled_flag && entropy_coding_sync_enabled_flag equal to 0"".[[BR]] To follow such restriction, sentences refer to tiles_enabled_flag=1 and entropy_coding_sync_enabled_flag=1 should be removed. See definitions of num_entry_point_offsets and entry_point_offset[ i ].[[BR]] To preserve the possibility of tiles_enabled_flag=1 and entropy_coding_sync_enabled_flag=1 (for other future profile), the initialization and memorization condition in 9.3 need to be revised.[[BR]] Also the byte_alignment( ) issue mentioned in #659 needs to be solved." conrad.ho D10 (L1003) v2 797 resSamples is not defined to be 0 when skip_flag is equal to 1 Text D10 (L1003) v2 defect bbross closed 2012-10-14T12:51:27+02:00 2013-02-19T22:58:13+01:00 "In section 8.6.5 it is specified how the reconstruction is obtained. It is using predSamples and resSamples to obtain recSamples. However resSamples are not specified to be 0 when skip_flag[x0][yo] is equal to 1. Not sure of the best place to indicate this. One possibility is in section of 8.5.4. Perhaps something like what is added below between """" .. """": Depending on no_residual_syntax_flag, the following applies: – If no_residual_syntax_flag is equal to 1 """"or skip_flag[xC][yC] is equal to 1"""", all samples of the (nCSL)x(nCSL) array resSamplesL and all samples of the two (nCSC)x(nCSC) arrays resSamplesCb and resSamplesCr are set equal to 0. " Kenneth D10 (L1003) v2 810 Table 9-32 : maxBinIdxCtx is incorrect for some syntax elements Text D10 (L1003) v2 defect bbross closed 2012-10-23T17:04:57+02:00 2013-02-19T22:54:52+01:00 "Some syntax elements have bypass bins which are not of a prefix and suffix. The value of maxBinIdxCtx specified in table 9-32 might be wrong for some of them. + sao_type_idx_luma and sao_type_idx_chroma : maxBinIdxCtx should be 1 instead of 0 + merge_idx : maxBinIdxCtx can be 1, 2 or 3 but not 0. Since table 9-37 specifies the bypass type for bins 1, 2 and 3, a coherent choice is 3 for maxBinIdxCtx. Also, in table 9-37, we should fill binIdx 3 and 4 with na. Best regards, Phuong Nguyen." PhuongNguyen D10 (L1003) v2 862 7.3.2.1, 7.3.2.2, condition involving {vps,sps}_sub_layer_ordering_info_present_flag is inverted Text D10 (L1003) v2 defect bbross closed 2012-11-26T23:35:36+01:00 2013-02-19T23:01:32+01:00 "In 7.3.2.2, seq_parameter_set_rbsp(): {{{ for( i = ( sps_sub_layer_ordering_info_present_flag ? sps_max_sub_layers_minus1 : 0 ); i <= sps_max_sub_layers_minus1; i++ ) { ... } }}} Will only loop once when sps_sub_layer_ordering_info_present_flag = 1. Which has the opposite interpretation of 7.4.2.2: sps_sub_layer_ordering_info_present_flag equal to 1 specifies that sps_max_dec_pic_buffering[ i ], sps_max_num_reorder_pics, and sps_max_latency_increase[ i ] are present for sps_max_sub_layers_minus1 + 1 sub-layers, sps_sub_layer_ordering_info_present_flag equal to 0 specifies that the values of sps_max_dec_pic_buffering[ sps_max_sub_layers_minus1 ], sps_max_num_reorder_pics[ sps_max_sub_layers_minus1 ] , and sps_max_latency_increase[ sps_max_sub_layers_minus1 ] apply to all sub-layers. " davidf D10 (L1003) v2 875 8.5.3.1.1 : singleMCLFlag = 1 leads to the same vector for every PB of the CB Text D10 (L1003) v2 defect bbross closed 2012-11-30T21:30:37+01:00 2013-02-19T22:44:49+01:00 "In the 8.5.3.1.1 chapter, singleMCLFlag is used : ""When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS. NOTE – When singleMCLFlag is equal to 1, all the prediction units of the current coding unit share a single merge candidate list, which is identical to the merge candidate list of the 2Nx2N prediction unit."" At the end of the chapter we have: ""The following assignments are made with N being the candidate at position merge_idx[ xP][ yP ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP][ yP ] ] ) and X being replaced by 0 or 1: mvLX[ 0 ] = mvLXN[ 0 ] (8 79) mvLX[ 1 ] = mvLXN[ 1 ] (8 80) refIdxLX = refIdxLXN (8 81) predFlagLX = predFlagLXN (8 82)"" ============ So when singleMCLFlag = 1, since xP=xC and yP=yC for every PB of the CB, in this case every PB of the CB has the same result : mvLX, refIdxLX, predFlagLX. My understanding is that, according to the note, the aim of singleMCLFlag=1, is that every PB of the CB has the same candidate list, and not necessarily the same vector. Moreover, there is a value of merge_idx[][] for every PB of the CB in the bitstream and here we only use the first one of the CB. My proposal is that the initial values of xP and yP are kept and used in merge_idx. The text would be modified this way : Let's set xP_init to xP, and yP_init to yP. ""When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS."" ... ""The following assignments are made with N being the candidate at position merge_idx[ '''xP_init'''][ '''yP_init''' ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ '''xP_init'''][ '''yP_init''' ] ] ) and X being replaced by 0 or 1:"" " Jing-Jing Chung D10 (L1003) v2 914 The behavior of transform_skip_flag as 0 is not specified. Text D10 (L1003) v2 defect bbross closed 2012-12-15T02:42:45+01:00 2013-02-19T21:55:21+01:00 "In the latest HEVC spec, there is no specified behavior when transform_skip_flag is 0. We suggest the following semantics change. Before: transform_skip_enabled_flag equal to 1 specifies that transform_skip_flag may be present in the residual coding syntax. transform_skip_enabled_flag equal to 0 specifies that transform_skip_flag is not present in the residual coding syntax. transform_skip_flag[ x0 ][ y0 ][ cIdx ] specifies whether a transform is applied to the associated transform block or not: The array indices x0, y0 specify the location ( x0, y0 ) of the top-left luma sample of the considered transform block relative to the top-left luma sample of the picture. The array index cIdx specifies an indicator for the colour component; it is equal to 0 for luma, equal to 1 for Cb, and equal to 2 for Cr. transform_skip_flag[ x0 ][ y0 ][ cIdx ] equal to 1 specifies that no transform will be applied to the current transform block. When transform_skip_flag[ x0 ][ y0 ][ cIdx ] is not present, it is inferred to be equal to 0. After: transform_skip_enabled_flag equal to 1 specifies that transform_skip_flag may be present in the residual coding syntax. transform_skip_enabled_flag equal to 0 specifies that transform_skip_flag is not present in the residual coding syntax and transform will be applied to the current transform block. transform_skip_flag[ x0 ][ y0 ][ cIdx ] specifies whether a transform is applied to the associated transform block or not: The array indices x0, y0 specify the location ( x0, y0 ) of the top-left luma sample of the considered transform block relative to the top-left luma sample of the picture. The array index cIdx specifies an indicator for the colour component; it is equal to 0 for luma, equal to 1 for Cb, and equal to 2 for Cr. transform_skip_flag[ x0 ][ y0 ][ cIdx ] equal to 1 specifies that no transform will be applied to the current transform block. transform_skip_flag[ x0 ][ y0 ][ cIdx ] equal to 0 specifies that transform will be applied to the current transform block. When transform_skip_flag[ x0 ][ y0 ][ cIdx ] is not present, it is inferred to be equal to 0. " yyu D10 (L1003) v2 960 "specification of ""pps_scaling_list_data_present_flag equal to 0""" Text D10 (L1003) v2 defect bbross closed 2013-01-18T12:56:16+01:00 2013-01-24T11:01:55+01:00 "It seems to be inconsistent in case of ""pps_scaling_list_data_present_flag equal to 0"". at 7.4.2.3 Picture parameter set RBSP semantics, pps_scaling_list_data_present_flag equal to 0 specifies that the scaling lists used for the pictures referring to the picture parameter set is inferred to be equal to those specified by the active sequence parameter set. ... When scaling_list_enable_flag is equal to 1 and pps_scaling_list_data_present_flag is equal to 0, the default scaling list data is used to derive the array ScalingFactor as described in the scaling list data semantics 7.4.6. It seems that first one is correct." sasai D10 (L1003) v2 966 No max value for abs_delta_rps_minus1 Text D10 (L1003) v2 defect bbross closed 2013-01-20T23:44:57+01:00 2013-01-24T11:03:35+01:00 No maximum value is provided in the semantics of abs_delta_rps_minus1 for this syntax element. fbossen D10 (L1003) v2 971 slice_segment_address value range should starts from 0 Text D10 (L1003) v2 defect bbross closed 2013-01-23T01:53:30+01:00 2013-02-19T21:51:50+01:00 "7.4.8.1 General slice segment header semantics slice_segment_address specifies the address of the first coding tree block in the slice segment, in coding tree block raster scan of a picture. The length of the slice_segment_address syntax element is Ceil( Log2( PicSizeInCtbsY ) ) bits. The value of slice_segment_address shall be in the range of 1 to PicSizeInCtbsY − 1, inclusive and the value of slice_segment_address shall not be equal to the value of slice_segment_address of any other coded slice segment NAL unit of the same coded picture. When slice_segment_address is not present, it is inferred to be equal to 0. ""The value of slice_segment_address shall be in the range of 1 to PicSizeInCtbsY − 1"" should be replaced by ""The value of slice_segment_address shall be in the range of 0 to PicSizeInCtbsY − 1"". Otherwise the last sentence ""When slice_segment_address is not present, it is inferred to be equal to 0."" violates this rule." xiaozhong D10 (L1003) v2 975 "Typo in ""8.7.2.3 Derivation process of boundary filtering strength""" Text D10 (L1003) v2 defect bbross closed 2013-01-24T10:34:54+01:00 2013-02-19T21:51:18+01:00 "{{{ #!html NOTE 2 – The number of motion vectors that are used for the prediction of a luma prediction block with
lop left luma sample covering ( xB, yB ), is equal to PredFlagL0[ xB ][ yB ] + PredFlagL1[ xB ][ yB ]. }}}" jeunder D10 (L1003) v2 978 Wrong syntax for lt_idx_sps[ i ] (7.3.7.1 General slice segment header syntax) Text D10 (L1003) v2 defect bbross closed 2013-01-25T10:58:09+01:00 2013-02-19T21:42:01+01:00 " {{{ if( i < num_long_term_sps && num_long_term_ref_pics_sps > 1) lt_idx_sps[ i ] else { }}} should be {{{ if( i < num_long_term_sps) { if( num_long_term_ref_pics_sps > 1) lt_idx_sps[ i ] } else { }}} " stefane D10 (L1003) v2 979 Incorrect ctxIdxTable entries for part_mode in Table 9-32 Text D10 (L1003) v2 defect bbross closed 2013-01-25T20:37:21+01:00 2013-02-19T21:40:53+01:00 In Table 9-32, the three ctxIdxTable entries for part_mode should be Table 9-12 instead of Table 9-11. stefane D10 (L1003) v2 980 9.2.3.2.4: add end_of_sub_stream_one_bit case Text D10 (L1003) v2 defect bbross closed 2013-01-26T07:40:10+01:00 2013-03-06T16:09:20+01:00 "In 9.2.3.2.4 Decoding process for binary decisions before termination, the sentence When decoding end_of_sub_stream_one_bit, this last bit inserted in register codIOffset is interpreted as alignment_bit_equal_to_one. should be added after When decoding end_of_slice_segment_flag, this last bit inserted in register codIOffset is interpreted as rbsp_stop_one_bit. " stefane D10 (L1003) v2 982 missing definitions for LumaWeightL1, ChromaWeightL1, ChromaOffsetL1 Text D10 (L1003) v2 defect bbross closed 2013-01-31T01:04:01+01:00 2013-02-19T21:29:02+01:00 "In 7.4.7.4, LumaWeightL1[i], ChromaWeightL1[i][j], and ChromaOffsetL1[i][j] should be added to the list of things that have the same semantics as the L0 versions. Additionally, ""L0"" replaced by ""L1"" should be added to the substitution list. It is a good idea to check other sections for similarly missing definitions." dthoang D10 (L1003) v2 997 invalid case: num_short_term_ref_pic_sets == 0 && short_term_ref_pic_set_sps_flag == 1 Text D10 (L1003) v2 defect bbross closed 2013-02-02T09:06:43+01:00 2013-02-19T21:50:51+01:00 "Currently, short_term_ref_pic_set_sps_flag can be equal to 1 even if num_short_term_ref_pic_sets is equal to 0, which is not a valid combination. This condition should be disallowed, either semantically by adding a constraint to short_term_ref_pic_set_sps_flag (shall not be equal to one when num_short_term_ref_pic_sets is equal to 0) or by a syntax constraint {{{ if( num_short_term_ref_pic_sets > 0 ) short_term_ref_pic_set_sps_flag }}} and a default value for short_term_ref_pic_set_sps_flag (When not present, the value of short_term_ref_pic_set_sps_flag is inferred to be equal to 0.)." stefane D10 (L1003) v2 999 possible bug in use of sps_max_latency_increase for bumping Text D10 (L1003) v2 defect bbross closed 2013-02-04T18:47:53+01:00 2013-02-19T21:28:17+01:00 "In C.5.2.2, Output and removal of pictures from the DPB, and C.5.2.3, Picture decoding, marking, additional bumping, and storage, in the sentence – There is at least one picture in the DPB that is marked as ""needed for output"" for which the associated variable PicLatencyCount is greater than or equal to sps_max_latency_increase[ HighestTid ]. I suspect that sps_max_latency_increase[ HighestTid ] should be replaced with MaxLatencyPictures[ HighestTid ] and the sentence should be conditioned with when sps_max_latency_increase[ HighestTid ] is not equal to 0 " stefane D10 (L1003) v2 1000 name collision with StRpsIdx Text D10 (L1003) v2 defect bbross closed 2013-02-04T21:20:38+01:00 2013-02-19T21:25:04+01:00 "JCTVC-L1003_v17 introduced a naming conflict by renaming RIdx to StRpsIdx, which happens to be an existing variable name. In 7.4.6.1, The variable StRpsIdx is derived as follows: – If short_term_ref_pic_set_sps_flag is equal to 1, StRpsIdx is set equal to short_term_ref_pic_set_idx. – Otherwise, StRpsIdx is set equal to num_short_term_ref_pic_sets. In 7.4.7, The variable StRpsIdx is derived as follows. StRpsIdx = idxRps − ( delta_idx_minus1 + 1 ) (7-42) Furthermore, in 8.3.2, there is this note: NOTE 2 – A value of StRpsIdx in the range of 0 to num_short_term_ref_pic_sets − 1, inclusive, indicates that a short-term reference picture set from the active SPS is being used, where StRpsIdx is the index of the short-term reference picture set to the list of short-term reference picture sets in the order in which they are signalled in the SPS. StRpsIdx equal to num_short_term_ref_pic_sets indicates that a short-term reference picture set explicitly signalled in the slice header is being used. " dthoang D10 (L1003) v2 1010 Minor typo Text D10 (L1003) v2 defect bbross closed 2013-02-16T04:14:08+01:00 2013-02-19T21:12:54+01:00 In JCTVC-L1003_v21.doc, Page 63, there are two equations with the same number (7-2). junxu D10 (L1003) v2 740 8.6.1 : qPy_prev derivation when entropy_coding_sync_enalbed_flag = 1 is incorrect Text D10 (L1003) v2 enhancement bbross closed 2012-09-13T08:54:27+02:00 2013-03-06T16:45:07+01:00 "In chapter 8.6.1 : Derivation process for quantization parameters, the following condition to derive of qPY_prev is incorrect : ""The current quantization group is the first quantization group in a coding tree block row and entropy_coding_sync_enabled_flag is equal to 1."" (taking into account ticket #721) According to entropy_coding_sync_enabled_flag definition : ""'''entropy_coding_sync_enabled_flag''' equal to 1 specifies that a specific synchronization process for context variables is invoked before decoding the first coding tree block of a row of coding tree blocks in each tile..."" the condition should be : The current quantization group is the first quantization group in a coding tree block row '''of a tile''' and entropy_coding_sync_enabled_flag is equal to 1." Jing-Jing Chung D10 (L1003) v2 903 Ambiguity in binarization of coeff_abs_level_remaining Text D10 (L1003) v2 enhancement bbross closed 2012-12-12T10:56:54+01:00 2013-03-06T16:39:48+01:00 "In section 9.2.2.8 Binarization process for coeff_abs_level_remaining the text reads: cLastAbsLevel is set equal to baseLevel + coeff_abs_level_remaining[ n + 1 ] However, by the time coeff_abs_level_remaining[n] is being decoded, baseLevel has been reassigned a new value, so cLastAbsLevel is not necessarily the same as the absolute value of the last TransCoeffLevel. The full text reads: cLastAbsLevel is set equal to baseLevel + coeff_abs_level_remaining[ n + 1 ] and cLastRiceParam is set equal to the value of cRiceParam that has been derived during the invocation of the binarization process as specified in this subclause for the syntax element coeff_abs_level_remaining[ n + 1 ] of the same transform block. so I assume that the intention is that the value for both cLastRiceParam and baseLevel should be taken from the previous invocation. Perhaps the wording could be improved? " peterderivaz D10 (L1003) v2 969 Binarization of coeff_abs_level_remaining Text D10 (L1003) v2 enhancement bbross closed 2013-01-22T11:47:03+01:00 2013-02-19T21:11:04+01:00 "The description of binarization of coeff_abs_level_remaining in the specification is confusing and ambiguous. I propose replacing the last three paragraphs of 9.2.2.8 with the following text. ""The binarization of coeff_abs_level_remaining consists of a prefix part and a suffix part. The prefix part of the binarization is derived by invoking the TU binarization process as described in subclause 9.2.2.2 with Min( 4, coeff_abs_level_remaining[ n ] >> cRiceParam ) as input and cMax=4. When coeff_abs_level_remaining[n] is greater or equal to cTRMax, the suffix bin string is derived using the EGk binarization as specified in subclause 9.2.2.4 for the suffix part ( coeff_abs_level_remaining[ n ] − cTRMax ) with the Exp-Golomb order k set equal to cRiceParam + 1. Otherwise, the suffix string is cRiceParam bit long and it is specified by the binary representation of coeff_abs_level_remaining[ n ] − ( (coeff_abs_level_remaining[ n ] >> cRiceParam ) << cRiceParam )."" I've checked this logic against reference software and I believe it to be accurate. " eugene.kuznetsov D10 (L1003) v2 1004 harmonize requirement for access unit that follows end of sequence NAL unit and end of bitstream NAL unit Text D10 (L1003) v2 enhancement bbross closed 2013-02-08T02:23:26+01:00 2013-02-19T21:14:35+01:00 "In 7.4.1.4.2, It is a requirement of bitstream conformance that, when present, the next access unit after an access unit that contains an end of sequence NAL unit shall be an IDR access unit, a BLA access unit, or a CRA access unit. It is a requirement of bitstream conformance that, when present, the next access unit after an access unit that contains an end of bitstream NAL unit shall be an IRAP access unit, which may be an IDR access unit, a BLA access unit, or a CRA access unit. These two sentences uses slightly different wording (IRAP not present in first) to express the same restriction. It seems that the two sentences can be combined into one sentence like this: It is a requirement of bitstream conformance that, when present, the next access unit after an access unit that contains an end of sequence NAL unit or an end of bitstream NAL unit shall be an IRAP access unit, which may be an IDR access unit, a BLA access unit, or a CRA access unit. " dthoang D10 (L1003) v2 692 frame definition missing Text D10 (L1003) v2 defect bbross closed 2012-08-23T16:13:35+02:00 2013-02-19T23:01:06+01:00 "There are 60 occurrences of ""frame"" in the D8 d7 however this term is not defined in the Definitions chapter. Besides, I suggest that: -in ""8.7.2.3 Derivation process of boundary filtering strength"" -in Table E-1 -... ""frame"" should be substituted by ""picture"" " pandrivon D10 (L1003) v2 935 Possible confusion in removal of pictures from DPB Text D10 (L1003) v2 defect bbross closed 2013-01-03T11:20:22+01:00 2013-01-24T11:06:46+01:00 "In section C.5.3 ""Output and removal of pictures from the DPB"" the text says that the bumping process is invoked (before decoding the current picture) until the number of pictures in the DPB is _strictly_ less than sps_max_dec_pic_buffering. Sequences produced by the reference encoder (such as using 9.1rc1 with cfg/encoder_randomaccess_main.cfg) use 4 reference frames (num_negative_pics=4) and set sps_max_dec_pic_buffering to 4. This causes a problem because the bumping process tries to reduce the DPB to 3, but 4 reference frames are needed. The reference decoder does not have a problem because lines 178-184 of TDecTop.cpp read: 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 ); } and so the reference decoder simply increases the size of the decoded picture buffer without complaining. (Additionally, m_iMaxRefPicNum is initialised on line 143 to a larger value than should be necessary.) My guess is that the text should change to say that the bumping should be invoked while the number of pictures is _greater_ than sps_max_dec_pic_buffering[TemporalId]. " peterderivaz D10 (L1003) v2 977 Merge and skip list generation text equivalent but subtly different Text D10 (L1003) v2 defect bbross closed 2013-01-24T12:24:45+01:00 2013-02-19T21:45:09+01:00 "In Section 8.5.3.1, Derivation process for motion vector components and reference indices.... the clauses defining the derivation processes for the skip and merge vectors seem completely equivalent, but have subtly different wording (typically differing in the use of commas vs the word ""and""). If they are truly equivalent, either they could be merged into one clause, or identical text could be used for both clauses in order to make it clearer that they are equivalent. " rikallen D10 (L1003) v2 1001 Derivation process for chroma motion vectors Text D10 (L1003) v2 defect bbross closed 2013-02-05T04:24:31+01:00 2013-02-19T21:22:27+01:00 "In 8.5.3.1.9 Derivation process for chroma motion vectors of L1003_v12, inputs are mvLX and refIdLX. But refIdLX is not used in this process" djpark0115 D10 (L1003) v2 1003 Inconsistent variable naming Text D10 (L1003) v2 defect bbross closed 2013-02-06T23:26:25+01:00 2013-02-19T21:16:03+01:00 "Version: d10 v19 In the ""We're down to this??"" category: the variables BitDepthY and BitDepthC are typed inconsistently. In most places the Y/C is a subscript, but in a few places the Y/C is just an upper-case letter. Those locations are: Section 7.4.2.10, 8.4.4.2.3, and 8.7.2. " hellman D10 (L1003) v2 1006 minor typos Text D10 (L1003) v2 defect bbross closed 2013-02-11T19:51:34+01:00 2013-02-19T21:13:52+01:00 In the definition of coded video sequence under NOTE 4, ''equa'' should be replaced by ''equal''. dthoang D10 (L1003) v2 1002 Redundant intra-mode checking in mvp candidates Text D10 (L1003) v2 enhancement bbross closed 2013-02-06T04:46:26+01:00 2013-03-06T16:29:27+01:00 "In 8.5.3.1.6 Derivation process for motion vector predictor candidates, Condition ""CuPredMode[ xAk][ yAk ] is not equal to MODE_INTRA"" is redundant because the condition is checked in 6.4.2 Derivation process for prediction block availability" djpark0115 D10 (L1003) v23 1014 9.2.1.4 : insufficient condition for the invocation of the process Text D10 (L1003) v23 defect bbross closed 2013-02-21T14:19:56+01:00 2013-03-06T15:52:05+01:00 "In 9.2.1.4 Initialization process for the arithmetic decoding engine : ""This process is invoked before decoding the first coding tree block of a slice segment."" This condition is not sufficient because arithmetic decoding engine is also initialized when we start a new tile or a new line in WPP. So either we remove this line or we list all the conditions as shown in 9.2.1 Initialization process." PhuongNguyen D10 (L1003) v23 1015 wrong flag in figure 9-4 Text D10 (L1003) v23 defect bbross closed 2013-02-21T16:08:28+01:00 2013-03-06T15:52:28+01:00 In the figure 9-4, dependent_slice_segment_flag should be replaced by dependent_slice_segments_enabled_flag. PhuongNguyen D10 (L1003) v23 1016 Maximum value for log2_parallel_merge_level_minus2 Text D10 (L1003) v23 defect bbross closed 2013-02-23T03:27:48+01:00 2013-03-06T15:52:55+01:00 " In the semantics for log2_parallel_merge_level_minus2, I believe the maximum allowed value should be changed from Log2MinCbSizeY-2 to Log2MaxCbSizeY-2. This would make the text consistent with the value used prior to D10 v20 cleanup (log2_min_luma_coding_block_size_minus3 + 1 + log2_diff_max_min_luma_coding_block_size). " bheng D10 (L1003) v23 1018 Specification sometimes produces an extra alignment byte when using tiles Text D10 (L1003) v23 defect bbross closed 2013-02-25T20:59:37+01:00 2013-03-06T15:53:26+01:00 "In 7.3.8.1 General slice segment data syntax of JCTVC-L1003_v24 the syntax calls byte_alignment when a new tile is detected. The syntax for byte_alignment emits a 1 followed by zeros until the stream is aligned. However, the decoder implementation in function TComInputBitstream::readOutTrailingBits of TComBitStream.cpp contains the code: Void TComInputBitstream::readOutTrailingBits () { UInt uiBits = 0; while ( ( getNumBitsLeft() > 0 ) && (getNumBitsUntilByteAligned()!=0) ) { read ( 1, uiBits ); } } which will not emit a 1 if the stream is already aligned. This code is called from TDecSbac::updateContextTables when the CABAC engine needs to be reinitialized. Which is the correct behaviour? (Or have I misunderstood something?)" peterderivaz D10 (L1003) v23 1020 A.4.1 Reference to MinCr being in Table A-1 Text D10 (L1003) v23 defect bbross closed 2013-02-26T19:33:15+01:00 2013-03-06T15:56:42+01:00 "In section A.4.1 General tier and level limits. After bullet points 'a' to 'i', there is the sentence;- 'The use of the MinCr parameter column of Table A 1 is specified in subclause A.4.2.' 'MinCr' was moved to Table A-2 in section A.4.2 a while ago, so I think this entire sentence can be deleted from section A.4.1 " agoudie D10 (L1003) v23 1021 Possible error in Sample Adaptive Offset for disabling chroma filtering between slices Text D10 (L1003) v23 defect bbross closed 2013-02-27T12:45:03+01:00 2013-03-06T15:58:21+01:00 "In JCTVC-L1003_v24 ""Coding tree block modification process"" 8.7.3.2 the text constructs the modified sample locations in luma coordinates as ( xSYik′, ySYjk′ ) = ( xSYi + hPos[ k ], ySYj + vPos[ k ] ) (8 345) However, for a chroma sample at xSi=31 and hPos[k]==1 we would get xSYi = 31*2 = 62 xSYik' = xSYi + 1 = 62 + 1 = 63 and so when we compute the expression MinTbAddrZs[ xSYik′ >> Log2MinTrafoSize ][ ySYjk′ >> Log2MinTrafoSize ] we will end up examining the same transform block as the current sample and so neither condition which disable filtering across slices would activate. This will mean that the chroma would end up filtering across the slice edge even if slice_loop_filter_across_slices_enabled_flag is equal to 0." peterderivaz D10 (L1003) v23 1029 incorrect header for Table 9-35 Text D10 (L1003) v23 defect bbross closed 2013-02-28T21:40:26+01:00 2013-03-06T15:58:52+01:00 The second column header for Table 9-35 should read '''Bin string''' instead of '''prefix'''. dthoang D10 (L1003) v23 1164 A close bracket in Equation (C-11) Text D10 (L1003) v23 defect closed 2013-09-19T06:28:28+02:00 2018-01-22T08:44:35+01:00 "Hi. I think a close bracket "")"" is necessary at the end of equation for tmpCpbRemovalDelay in (C-11). tmpCpbRemovalDelay = Max( ( auCpbRemovalDelayDeltaMinus1 + 1 ), Ceil( ( InitCpbRemovalDelay[ SchedSelIdx ] ÷ 90000 + AuFinalArrivalTime[ n − 1 ] − AuNominalRemovalTime[ n − 1 ] ) ÷ ClockTick ) ''')''' " o.nakagami D10 (L1003) v23 1189 wrong cross-reference Text D10 (L1003) v23 defect closed 2013-10-30T22:29:27+01:00 2018-01-22T08:45:30+01:00 "The following subclause indices '8.5.3.2.1' and '8.5.3.2.2' in JCT3V-N1003_r1 should be replaced by '8.5.3.2.2' and '8.5.3.2.3', respectively. log2_parallel_merge_level_minus2 plus 2 specifies the value of the variable Log2ParMrgLevel, which is used in the derivation process for luma motion vectors for merge mode as specified in subclause 8.5.3.2.1 and the derivation process for spatial merging candidates as specified in subclause 8.5.3.2.2. The value of log2_parallel_merge_level_minus2 shall be in the range of 0 to CtbLog2SizeY − 2, inclusive. " lizhang D10 (L1003) v23 1017 Capitalisation of ctbAddrRsToTs and ctbAddrTsToRs Text D10 (L1003) v23 defect bbross closed 2013-02-25T15:16:22+01:00 2013-03-06T16:16:55+01:00 "A couple of capital letters are missing. In the semantics for dependent_slice_segment_flag SliceAddrRs is computed based on ctbAddrTsToRs[ ctbAddrRsToTs[ slice_segment_address ] − 1 ] I think this should be CtbAddrTsToRs[ CtbAddrRsToTs[ slice_segment_address ] − 1 ] " peterderivaz D10 (L1003) v23 1022 """Scaling and transformation process"" is sometimes passed chroma locations" Text D10 (L1003) v23 defect bbross closed 2013-02-27T14:05:44+01:00 2013-03-06T16:17:37+01:00 "In JCTVC-L1003_v24 the first input to ""8.6.2 Scaling and transformation process"" is ""a luma location (xT,yT)"". In ""8.5.4.2 Decoding process for chroma residual blocks"" the input is correctly generated as a luma location. However, in ""8.4.4.1 General decoding process for intra blocks"" the input is the location (xB0, yB0) which has not been converted to luma coordinates. " peterderivaz D10 (L1003) v23 1023 Cabac process 9.2 uses end_of_slice_segment_flag before it has been read Text D10 (L1003) v23 defect bbross closed 2013-02-27T15:21:44+01:00 2013-03-06T16:19:19+01:00 "In JCTVC-L1003_v24 ""9.2 CABAC parsing process for slice segment data"" the text says that the storage process is applied ""When ending the parsing of the coding tree syntax in 7.3.8.2"". However, the storage process depends on the syntax element end_of_slice_segment_flag which is only read (in slice_segment_data) after the coding_tree_unit. I assume that the storage process should actually applied immediately after reading ""end_of_slice_segment_flag""." peterderivaz D10 (L1003) v28 904 Mismatch with HM in derivation of ctxIdxInc for coeff_abs_level_greater1_flag Text D10 (L1003) v28 defect bbross closed 2012-12-12T11:19:22+01:00 2013-03-15T17:14:24+01:00 "In some corner cases, the text and HM disagree on the value of lastGreater1Ctx. In 9.2.3.1.5 ""Derivation process of ctxIdxInc for the syntax element coeff_abs_level_greater1_flag"" the variable lastGreater1Ctx is derived from the value of greater1Ctx in a previous subblock. In the HM code, greater1Ctx is set to 0 as soon as a nonzero value for coeff_abs_level_greater1_flag is decoded: See lines 1222->1229 of TDecSbac.cpp: if( uiBin == 1 ) { c1 = 0; if (firstC2FlagIdx == -1) { firstC2FlagIdx = idx; } } However, in the text, greater1Ctx is only cleared indirectly via the variable lastGreater1Flag. The difference occurs when coeff_abs_level_greater1_flag is set and n equals 0 and greater1Ctx is nonzero. The next time the process is called, it now has a different sub-block scan index i, and so the code that would clear greater1Ctx is not invoked. This means that the reference code ends up with greater1Ctx=0, while the text still has greater1Ctx != 0. " peterderivaz D10 (L1003) v28 1035 parentheses needed in equation for firstByte[k] Equation 7-40 Text D10 (L1003) v28 defect bbross closed 2013-03-05T18:57:13+01:00 2013-03-15T17:17:38+01:00 "The equation calculating firstByte[k] from the the syntax values entry_point_offset_minus1[] should have parenthesis around the terms entry_point_offset_minus1[n-1] + 1 to clearly indicate the + 1 is included in each term of the sum. The parenthesis was removed in version 20 apparently while clarifying the summation limits. " lkerofsky D10 (L1003) v28 1037 Additional ScanOrder required when Log2MinTrafoSize==3 Text D10 (L1003) v28 defect bbross closed 2013-03-06T15:27:10+01:00 2013-03-15T17:17:56+01:00 "Applies to JCTVC-L1003_v28 and earlier. When Log2MinTrafoSize==3, this means that luma will use 8x8 transform, but chroma can still use 4x4 transform. This results in a slight problem when a transform_unit with Log2TrafoSize==3 calls residual_coding( x0, y0, log2TrafoSize − 1, 1 ). The problem is that residual_coding accesses the array ScanOrder[ log2TrafoSize − 2 ][ scanIdx ][ lastSubBlock ][ 0 ], where the first index is 0. However, this array is defined in the semantics for ""log2_diff_max_min_transform_block_size"" only for blocksizes from Min( 2, Log2MinTrafoSize − 2 ) to 3. Perhaps the fix is to simply define the array for blocksizes from 0 to 3? Or maybe Max(0,Min(2,Log2MinTrafoSize-3))?" peterderivaz D10 (L1003) v28 1041 Undefined behaviour if num_ref_idx_l0_active_minus1 >= NumPocTotalCurr and ref_pic_list_modification_flag_l0==0 Text D10 (L1003) v28 enhancement closed 2013-03-12T11:57:53+01:00 2013-03-12T17:39:43+01:00 "What should be the behaviour if ref_pic_list_modification_flag_l0 == 0 and num_ref_idx_l0_active_minus1 >= NumPocTotalCurr? This is important in 8.3.4 ""Decoding process for reference picture lists construction"" of JCTVC-L1003_v29. RefPicList0[num_ref_idx_l0_active_minus1] is a function of RefPicListTemp0[num_ref_idx_l0_active_minus1], but this value will not have been defined if NumPocTotalCurr is too small. In other words, what should happen if num_ref_idx_l0_active_minus1 specifies more reference pictures than have been defined in the reference picture sets? I am guessing that this is not allowed, but I can't see where it is explicitly forbidden. I suggest adding an additional restriction to the semantics for num_ref_idx_l0_default_active_minus1 to prohibit this case. (A similar change would be needed for num_ref_idx_l1_default_active_minus1) " peterderivaz D10 (L1003) v28 1025 Three trivial clean-ups Text D10 (L1003) v28 defect bbross closed 2013-02-27T17:13:00+01:00 2013-03-15T17:18:37+01:00 "Subclause C.1, second paragraph below (C-1): * remove extra '.' in 'subclause .C.5.2.2' Subclause C.2.3, (C-11): * ""baseTime = AuNominalRemovalTime[ prevNonDiscardablePic )"" should be ""baseTime = AuNominalRemovalTime[ prevNonDiscardablePic /]/"" * remove the 'a' in ""... and a auCpbRemovalDelayDeltaMinus1 are the values ...""" mwi D10 (L1003) v28 1036 Trivial typo in flowchart for encoding bypass Text D10 (L1003) v28 defect bbross closed 2013-03-06T14:28:12+01:00 2013-03-15T17:19:34+01:00 "In JCTVC-L1003_v28: Figure 9-13 uses BinCountInNalUnits instead of BinCountsInNalUnits (i.e. a missing s)." peterderivaz D10 (L1003) v31 1043 Confusion about decoding engine initialization after pcm_flag Text D10 (L1003) v31 defect closed 2013-03-13T18:00:06+01:00 2013-03-17T18:54:09+01:00 "9.3 ""CABAC parsing process for slice segment data"" says that the decoding engine is initialized after reading pcm_flag and decoding a 1. This implies that a decoder should: 1. Read pcm_flag 2. Read 9 bits giving the start for ivlOffset 3. Discard alignment bits 4. Read PCM samples However, I suspect the intention is to have the decoding engine initialized only after reading the PCM samples: 1. Read pcm_flag 2. Discard alignment bits 3. Read PCM samples 4. Read 9 bits giving the start for ivlOffset (The reference decoder uses the second method in function TDecSbac::parseIPCMInfo)" peterderivaz D10 (L1003) v31 1044 Clarification about B prediction in P slices Text D10 (L1003) v31 defect closed 2013-03-14T17:01:31+01:00 2013-03-19T06:22:56+01:00 "If there is a B slice followed by a P slice, the collocated luma prediction block can be a B block. In this case, I believe that section 8.5.3.2.8 ""Derivation process for collocated motion vectors"" will set availableFlagL1Col=1 and thus produce a B predicted block inside the P slice. I assume that this is not actually allowed. Perhaps the derivation of availableFlagLXCol should set it to 0 if x==1 and slice_type is equal to P? " peterderivaz D10 (L1003) v33 1098 wrong POC referencing while building combined bi-predictive merging candidates Text D10 (L1003) v33 defect closed 2013-05-29T08:47:44+02:00 2013-05-30T04:24:19+02:00 "I found some weird condition from '8.5.3.2.3 Derivation process for combined bi-predictive merging candidates'. A merging candidate list mergeCandList includes temporal merge candidate, but POC comparison between L0combCandk and L1combCandk does not consider the case that L0combCandk or L1combCandk comes from temporal merge candidate, as in below: * ( DiffPicOrderCnt( RefPicList0[ refIdxL0l0Cand ], RefPicList1[ refIdxL1l1Cand ] ) != 0 ) | | ( mvL0l0Cand != mvL1l1Cand ) RefPicList0/1 are defined as L0/L1 list of a slice, so if l0Cand or l1Cand is temporal merging candidate then refPicListL0/1 of co-locate picture should be referred instead of RefPicList0/1. And in case that, num_ref_idx_l0_active_minus1 of current slice is lesser than num_ref_idx_l0_active_minus1 of co-located picture, RefPicList0[ refIdxL0l0Cand ] can cause referencing on undefined value. Is this intended behavior? " tee.jung D10 (L1003) v33 1200 Problems in 9.3.3.2 Truncated Rice (TR) binarization process Text D10 (L1003) v33 defect closed 2013-11-26T10:09:39+01:00 2018-01-22T06:46:00+01:00 "In 9.3.3.2, it says: When cMax is greater than synVal, the suffix of the TR bin string is present and it is derived as follows: – The suffix value of synVal, suffixVal, is derived as follows: suffixVal = synVal − ( ( prefixVal ) << cRiceParam ) (9 9) – The suffix of the TR bin string is specified by the binary representation of suffixVal. However, there are some problems: 1. The above process should not be applied when cRiceParam=0. 2. The suffix of the TR bin string is specified by the binary representation of suffixVal, which is a very ambiguous expression. By checking the source code, I think it should be modified as: The suffix of the TR bin string is specified by invoking the fixd-length binarization process as specified in subclause 9.3.3.4 with cRiceParam as input. " jicheng D10 (L1003) v33 1348 Inconsistency in HEVC spec and between the spec and HM Text D10 (L1003) v33 defect closed 2014-11-12T15:54:51+01:00 2018-01-22T10:21:51+01:00 "We found some inconsistency in HEVC spec and between the spec and HM software. We would appreciate if someone can help to clarify them. 1.Use of “concatenation_flag”: The meaning of this flag being either “0” or “1” as described in Annex C.2.3 Eq(C-11)(on “concatenationFlag”) is different from that described later in Annex D.3.2 (on “concatenation_flag”). Based on common sense and also as implemented in HM encoder, it seems that the description in Annex C.2.3 would be correct, i.e. concatenation_flag = 0, meaning no extra constraint related w/ prevNonDiscardablePic is needed, and the derivation of nominal removal time would be simpler and the same as in AVC. 2.The setting of “nuh_temporal_id_plus1”: In HEVC spec 7.4.2.2, when explaining the setting of right values for “TemporalId for non-VCL NAL units”,the last statement is that “Otherwise, TemporalId shall be greater than or equal to the TemporalId of the access unit containing the NAL unit.” However, in the following “NOTE 9”, it says “When the NAL unit is a non-VCL NAL unit, the value of TemporalId is equal to the minimum value of the TemporalId values of all access units to which the non-VCL NAL unit applies.” The “greater than” in the 1st statement is contradictory w/ the “minimum” in the 2nd statement. From HM encoder, we see that it is implemented to be the “minimum” as stated in the 2nd statement. 3. Inconsistency between HM encoder and HEVC spec: For HEVC VPS and SPS parameters “sps_max_dec_pic_buffering_minus1[i]”, and “sps_num_reorder_pics[i]” (same things for “vps_” as well), they are coded in HM encoder functions CodeSPS() and CodeVPS(). The related variables NumReorderPics and MaxDecPicBuffering of layer i are set the same value of the involved layer index, i.e. “i”, which can be seen by tracing all the code w/ key words “setNumReorderPics” and “setMaxDecPicBuffering”. This setting, however, violates w/ the value constraint of vps/sps_max_num_reorder_pics[i] as stated in HEVC spec 7.4.3.1 and 7.4.3.2, where it basically says max_num_reorder_pics[i] has to be in the range of 0 to max_dec_pic_buffering_minus1[i], inclusive. Now, the current HM setting value of NumReorderPics is equal to the value of MaxDecPicBuffering, which will violate the constraint as stated in the spec. ========== Note that: the version of the HEVC spec we are using is L1003_v34. However, I couldn't find that version in the list. So I choose the closest one, L1003_v33. " gaow02 D10 (L1003) v33 1019 8.6.1 ctbAddr calculation in derivation of quantisation parameter Text D10 (L1003) v33 defect bbross closed 2013-02-26T19:17:11+01:00 2014-01-27T17:34:07+01:00 "I beleive a recent 'cleanup' of the 'ctbAddr' calculation has added brackets in the wrong place. Under bullet points 2 and 3, the address calculation is currently;- tmpX = xQg − ( 1 >> Log2MinTrafoSize ) tmpY = yQg >> Log2MinTrafoSize minTbAddrA = MinTbAddrZs[ tmpX ][ tmpY ] ctbAddrA = ( minTbAddrA >> 2 ) * (Log2CtbSizeY − Log2MinTrafoSize) (8 249) I beleive the brackets in the calculation of tmpX(/tmpY) and ctbAddrA(/B) should be;- tmpX = '''('''xQg − 1''')''' >> Log2MinTrafoSize ctbAddrA = minTbAddrA >> '''(''' 2 * (Log2CtbSizeY − Log2MinTrafoSize) ''')''' (8 249) (To calculate the location of transform block to the left/above, and then use shift as an equivalence to divide by the number of transform blocks in a CTU). " agoudie D10 (L1003) v33 1046 Possible errors in semantics for scaling_list data Text D10 (L1003) v33 defect closed 2013-03-18T14:32:30+01:00 2018-01-22T07:14:42+01:00 "== Range for loop variable == In 7.4.5 ""Scaling list data semantics"" the definition of ""scaling_list_pred_matrix_id_delta"" involves setting values for i in the range 0..Min(64,...), but the Table 7-6 is only defined for values up to 63. I believe the Min(64, should be changed to Min(63, Note that this appears twice in the definition of ""scaling_list_pred_matrix_id_delta"". == Default for DC value == When scaling_list_pred_mode_flag==0, the values for ScalingList are derived based on previous values of ScalingList. I believe there should be a similar derivation for the values of scaling_list_dc_coef_minus8 based on previous values. At the moment, `ScalingFactor[3][matrixId][0][0]` is based on `scaling_list_dc_coef_minus8[1][matrixId]` which will take its default value of 8 if `scaling_list_pred_matrix_flag[3][matrixId]==0`. The reference code appears to have code to deal with this case in TDecCavlc::parseScalingList {{{ if( sizeId > SCALING_LIST_8x8 ) { scalingList->setScalingListDC(sizeId,listId,((listId == scalingList->getRefMatrixId (sizeId,listId))? 16 :scalingList->getScalingListDC(sizeId, scalingList->getRefMatrixId (sizeId,listId)))); } }}}" peterderivaz D10 (L1003) v33 1047 condition of split_transform_flag Text D10 (L1003) v33 defect closed 2013-03-19T08:59:23+01:00 2013-04-12T00:43:34+02:00 "Shall if( log2TrafoSize <= Log2MaxTrafoSize && log2TrafoSize > Log2MinTrafoSize && trafoDepth < MaxTrafoDepth && !( IntraSplitFlag && ( trafoDepth = = 0 ) ) ) split_transform_flag[ x0 ][ y0 ][ trafoDepth ] be if( log2TrafoSize <= Log2MaxTrafoSize && log2TrafoSize > Log2MinTrafoSize && trafoDepth < MaxTrafoDepth && !( IntraSplitFlag && ( trafoDepth = = 0 ) ) && '''!interSplitFlag''' ) split_transform_flag[ x0 ][ y0 ][ trafoDepth ] in 7.3.8.8?" libin D10 (L1003) v33 1055 Typo in Section 9.3.3.9 of v34 Text D10 (L1003) v33 defect closed 2013-03-28T19:47:06+01:00 2018-01-22T07:16:14+01:00 There a typo in Section 9.3.3.9 of v34: cu_qp_delta_abs is used in a few places instead of coeff_abs_level_remaining. madhukar D10 (L1003) v33 1067 mismatch between HEVC text and HM reference software Text D10 (L1003) v33 defect closed 2013-04-08T12:12:27+02:00 2018-01-22T07:16:45+01:00 "Low-delay checking process is required for TMVP derivation. The process is carried out by comparing the POC values of current picture and its reference pictures. In HEVC text, the low-delay checking process is specified in the section of TMVP derivation (i.e. 8.5.3.2.8 Derivation process for collocated motion vectors), which means the low-delay checking process is done at block-level. However the low-delay checking process is performed at slice-level in HM reference software, where a low-delay flag is firstly determined at slice-level and then used in TMVP derivation. It seems the low-delay checking at block-level specified in HEVC text is not reasonable for practical design, since the low-delay checking process is only based on POC values, instead of any block-level information, and meanwhile the block-level low-delay checking increase complexity. Hence alignment with HM reference software is suggested for consideration. " sier D10 (L1003) v33 1075 collocated_from_l0 vs collocated_from_l0_flag Text D10 (L1003) v33 defect closed 2013-04-18T19:10:55+02:00 2018-01-22T07:17:25+01:00 "In a few places, collocated_from_l0_flag is referred to as collocated_from_l0, i.e. the ""_flag"" suffix missing." Parabola D10 (L1003) v33 1077 Log2MinIpcmCbSizeY range issue when MinCbLog2SizeY = 6 Text D10 (L1003) v33 defect closed 2013-04-21T19:47:04+02:00 2018-01-22T07:18:12+01:00 "In 7.4.3.2 Sequence parameter set RBSP semantics, for syntax element log2_min_pcm_luma_coding_block_size_minus3: ""The value of Log2MinIpcmCbSizeY shall be in the range of MinCbLog2SizeY to Min( CtbLog2SizeY, 5 ), inclusive."" Specifically for MinCbLog2SizeY = CtbLog2SizeY = 6 (discouraged but allowed when pcm_flag = 1): ""The value of Log2MinIpcmCbSizeY shall be in the range of 6 to 5, inclusive."" which is contradictory (assuming ranges are specified low to high). A similar issue exists for syntax element log2_diff_max_min_pcm_luma_coding_block_size. " stefane D10 (L1003) v33 1083 DeltaToDivisor in Table E-6 Text D10 (L1003) v33 defect closed 2013-05-03T09:47:49+02:00 2013-07-28T13:08:43+02:00 "(JCTVC-L1003 V34) In Table E-6, DeltaToDivisor is defined as 2 when frame_field_info_present_flag is equal to 1 and pic_struct is equal to 0. I think DeltaToDivisor should be 1 (not 2) in this case because ""pic_struct = 7"" (frame doubling, appears in the same CVS) case uses the same value (i.e. 2). " kazui D10 (L1003) v33 1086 Sum of the NumBytesInNalUnit equation for access unit n need correction Text D10 (L1003) v33 defect closed 2013-05-07T02:09:40+02:00 2018-01-22T07:18:49+01:00 "Following text in Sec A.4.2 h) ... The sum of the NumBytesInNalUnit variables for access unit n (with n greater than 0) shall be less than or equal to 1.5 * MaxLumaSr * ( AuCpbRemovalTime[ n ] − AyCpbRemovalTime[ n − 1 ] ) ÷ MinCr Need correction where ""AyCpbRemovalTime"" should be replaced by ""AuCpbRemovalTime""" sdoshi D10 (L1003) v33 1091 Description of Truncated Rice binarization Text D10 (L1003) v33 defect closed 2013-05-10T00:55:33+02:00 2018-01-22T07:19:06+01:00 "In section 9.3.3.2 Truncated Rice (TR) binarization process, the sentence ""The suffix of the TR bin string is specified by the binary representation of suffixVal"" does not specify the length of the suffix bin string. The length is fixed to cRiceParam. For example, if suffixVal=2 and cRiceParam=4, the suffix bin string is 0010 and not 10. The text can be corrected to say ""The suffix of the TR bin string is specified by the binary representation of suffixVal of length cRiceParam"". There is also an ambiguity about the order of bins - whether smaller binIdx corresponds to LSB or MSB. I am not sure what is implemented in HM. If it is same as Fixed-length (smaller binIdx = MSB), the statement can instead be worded as ""The suffix of the TR bin string is specified by the Fixed-length binarization specified in 9.3.3.4 with the value of syntax element set to suffixVal and parameter cMax set to (1 << cRiceParam) - 1." mtikekar D10 (L1003) v33 1092 Typo in 9.3.3.9 Binarization process for coeff_abs_level_remaining Text D10 (L1003) v33 defect closed 2013-05-10T17:31:52+02:00 2018-01-22T07:19:30+01:00 "The statement ""The prefix value of cu_qp_delta_abs, prefixVal, is derived as follows:"" should read ""The prefix value of coeff_abs_level_remaining, prefixVal, is derived as follows:""" mtikekar D10 (L1003) v33 1095 Undefined behaviour when choosing longterm reference pictures. Text D10 (L1003) v33 defect closed 2013-05-23T14:20:15+02:00 2013-05-24T14:00:20+02:00 "In the derivation process for the RPS and picture marking (equation 8-6 of JCTVC-L1003_v34) what should happen if there is more than one reference picture in the DPB with slice_pic_order_cnt_lsb equal to PocLtCurr[i]? For example, suppose MaxPicOrderCntLsb=16 and we have 4 short term frames in the DPB with POCs of 0,16,32,48. If the next picture decides to use: NumPocLtCurr=1 CurrDeltaPocMsbPresentFlag=0 PocLtCurr[0]=0 Which reference frame should be put into RefPicSetLtCurr[0]? The function TComSlice::xGetLongTermRefPic in the reference decoder simply selects the first match, but this behaviour does not appear to be defined in the specification. I wonder if this situation is meant to never occur? Section 8.3.2 ""Decoding process for reference picture set"" contains a number of requirements for bitstream conformance but they do not seem to rule out this case. Perhaps I have overlooked some requirement?" peterderivaz D10 (L1003) v33 1107 Possible contradiction with regard to picture latency Text D10 (L1003) v33 defect closed 2013-06-10T17:59:41+02:00 2013-07-28T13:05:56+02:00 "This ticket relates to spec sections 7.4.3.2 and C.5.2.3. Say I have a CVS with the following pictures (given in decoding order): || '''POC''' || 1 || 4 || 2 || 5 || 3 || || '''Reorder''' || 0 || 0 || 1 || 0 || 2 || || '''Latency''' || 0 || 2 || 0 || 1 || 0 || The reorder and latency values have been arrived at using the definitions in section 7.4.3.2: '''Reorder:''' the maximum allowed number of pictures that can precede any picture in the CVS in decoding order and follow that picture in output order '''Latency:''' the maximum number of pictures that can precede any picture in the CVS in output order and follow that picture in decoding order So in the SPS for this CVS, I have sps_max_num_reorder_pics=2 and sps_max_latency_increase_plus1=1, giving 2 as the maximum value for reorder and latency. Now I come to decode this CVS using the procedure in C.5.2.3. The process goes like this: 1.Decode POC 1. Store in DPB as 'needed for output'. No bumping on this step. DPB at end of this step: || POC || 1 || || PicLatencyCount || 0 || 2. Decode POC 4. No output. DPB at end of this step: || POC || 1 || 4 || || PicLatencyCount || 1 || 0 || 3. Decode POC 2. As NumDPB>2, invoke bumping and output POC 1. DPB at end of this step: || POC || 4 || 2 || || PicLatencyCount || 1 || 0 || 4. Decode POC 5. As NumDPB>2, invoke bumping and output POC 2. As PicLatencyCount for POC 4 is now 2, invoke bumping again and output POC 4. DPB at end of this step: || POC || 5 || || PicLatencyCount || 0 || The order of output will now end up as 1,2,4,3,5 instead of the expected 1,2,3,4,5. It seems like the condition in C.5.2.3 should be that PicLatencyCount is greater than SpsMaxLatencyPictures, rather than greater than or equal to." jackh D10 (L1003) v33 1110 Clarification needed in SPS ordering information semantics Text D10 (L1003) v33 defect closed 2013-06-13T18:16:14+02:00 2018-01-22T07:20:20+01:00 The definitions of sps_max_dec_pic_buffering_minus1, sps_max_num_reorder_pics and sps_max_latency_increase_plus1, which define ranges based on the corresponding parameters in the VPS, don't state what should be done in the case where vps_max_sub_layers_minus1!=sps_max_sub_layers_minus1. This is particularly a problem if vps_max_sub_layers_minus1= 5 should be ""na"" instead of ""bypass."" The reason is that sao_band_position[][][] if binarized as FL with cMax = 31, and thus requires only 5 bins. It is recommended that this fix be included in a future corrigendum or amendment of the specification." dthoang D10 (L1003) v33 1309 Potential for reference pictures to be reactivated across a CVS boundary Text D10 (L1003) v33 defect closed 2014-08-07T12:50:06+02:00 2018-01-22T08:41:20+01:00 "Section 8.3.2 of L1003 v34 says: When the current picture is an IRAP picture with NoRaslOutputFlag equal to 1, all reference pictures currently in the DPB (if any) are marked as ""unused for reference"". the clear intention being that there may be no pictures in a CVS that reference pictures from a preceding CVS. This is fine. However, later in the same section, it says this: All reference pictures that are included in RefPicSetLtCurr and RefPicSetLtFoll are marked as ""used for long-term reference"". This gives the potential for a BLA picture which has been spliced from another stream to reactivate a reference picture from the preceding CVS if it has an entry in its long term RPS which happens to have the same POC (or LSB thereof) as a picture remaining in the DPB from the preceding CVS. This has potential to subsequently mess up the DPB output process. As such reference pictures will never be actually used (they can only be used by RASLs which will not be decoded in this case anyway), I suggest that the second section above be modified to say: When the current picture is not an IRAP picture or NoRaslOutputFlag is equal to 0, all reference pictures that are included in RefPicSetLtCurr and RefPicSetLtFoll are marked as ""used for long-term reference"". " jackh D10 (L1003) v33 659 """byte_alignment"" presence condition in the slice_data syntax is not correct for tiles_enabled_flag=1 and entropy_coding_sync_enabled_flag=1" Text D10 (L1003) v33 enhancement bbross closed 2012-08-06T16:10:23+02:00 2018-01-22T07:01:44+01:00 "In chapter 7.3.4.1 of JCTVC-J1003_d3, the condition for the presence of byte_alignment() is : if( !end_of_slice_flag && ( ( tiles_enabled_flag && TileId[ CtbAddrTS ] != TileId[ CtbAddrTS − 1 ] ) || ( entropy_coding_sync_enabled_flag && CtbAddrTS % PicWidthInCtbs = = 0 ) ) ) byte_alignment( ) My understanding is that the byte_alignment is used for the entry_points of a slice. The condition is not correct, when tiles_enabled_flag=1 and entropy_coding_sync_enabled_flag=1. Indeed, in this case, there is an entry_point per tile Ctb row. Let's define the function TileWidthInCtbs[TileId], that returns the width of tile TileId in unit of Ctb. (If tiles_enabled_flag=0, this returns the picture width in unit of Ctb) The condition above becomes : if( !end_of_slice_flag && ( ( tiles_enabled_flag && TileId[ CtbAddrTS ] != TileId[ CtbAddrTS − 1 ] ) || ( entropy_coding_sync_enabled_flag && CtbAddrTS % TileWidthInCtbs[TileId[ CtbAddrTS ]] = = 0 ) ) ) byte_alignment( )" chung D10 (L1003) v33 826 Monochrome support Text D10 (L1003) v33 enhancement bbross closed 2012-11-04T09:34:37+01:00 2018-01-22T07:04:43+01:00 "The following changes to address handling of monochrome are identified (this ticket includes only changes not relating to the syntax tables): Section 8.4.1: After ""Depending on pcm_flag[ xC ][ yC ], the decoding process for chroma samples is specified as follows:"" Add the following line: ""- If ChromaArrayType is equal to 0, no chroma samples are decoded and this process is finished."" Section 8.5.3.2.2: ""For each chroma sample location..."" replace with: ""When ChromaArrayType is not equal to 0, for each chroma sample location..."" Section 8.5.4: ""2. The decoding process for chroma residual blocks..."" replace with: ""2. When ChromaArrayType is not equal to 0, the decoding process for chroma residual blocks..."" ""3. The decoding process for chroma residual blocks..."" replace with: ""3. When ChromaArrayType is not equal to 0, the decoding process for chroma residual blocks..."" Section 8.7.2.4.1: ""The filtering process for edges in the chroma coding blocks of current coding unit consists..."" replace with: ""If ChromaArrayType is equal to 0, this process is finished, otherwise (ChromaArrayType is not equal to 0), the filtering process for edges in the chroma coding blocks of the current coding unit consists..."" Section 8.7.2.4.2: ""The filtering process for edges in the chroma coding blocks of current coding unit consists..."" replace with: ""If ChromaArrayType is equal to 0, this process is finished, otherwise (ChromaArrayType is not equal to 0), the filtering process for edges in the chroma coding blocks of the current coding unit consists..."" Section 8.7.3: ""When slice_sao_chroma_flag of the current slice is equal to 1, the coding tree block modification process as specified in subclause 8.7.3.1 is invoked with recPicture set equal to recPictureCb, cIdx set equal to 1, ( rx, ry )..."" replace with: ""When slice_sao_chroma_flag of the current slice is equal to 1 and ChromaArrayType is not equal to 0, the coding tree block modification process as specified in subclause 8.7.3.1 is invoked with recPicture set equal to recPictureCb, cIdx set equal to 1, ( rx, ry )..."" ""When slice_sao_chroma_flag of the current slice is equal to 1, the coding tree block modification process as specified in subclause 8.7.3.1 is invoked with recPicture set equal to recPictureCb, cIdx set equal to 2, ( rx, ry )..."" replace with: ""When slice_sao_chroma_flag of the current slice is equal to 1 and ChromaArrayType is not equal to 0, the coding tree block modification process as specified in subclause 8.7.3.1 is invoked with recPicture set equal to recPictureCb, cIdx set equal to 2, ( rx, ry )..."" " crosewarne D10 (L1003) v33 843 Luma and chroma motion vector cleanup Text D10 (L1003) v33 enhancement bbross closed 2012-11-14T04:54:48+01:00 2018-01-22T10:56:02+01:00 "The present WD text supports motion vectors for luma (mvLX) and chroma (mvCLX). For 4:2:0, mvLX is assigned to mvCLX. For Range Extension (AHG7) work this separation will not be required (see JCTVC-K0383), thus mvCLX is redundant text. The following changes are suggested: 8.5.3 Decoding process for prediction units in inter prediction mode: ... The decoding process for prediction units in inter prediction mode consists of the following ordered steps: 1. The derivation process for motion vector components and reference indices as specified in subclause 8.5.3.1 is invoked with the luma coding block location ( xC, yC ), the luma prediction block location ( xB, yB ), the luma coding block size block nCS, the luma prediction block width and height, nPbW and nPbH, and the prediction unit index partIdx specifying as inputs and the luma motion vectors mvL0 and mvL1, the chroma motion vectors mvCL0 and mvCL1, the reference indices refIdxL0 and refIdxL1, and the prediction list utilization flags predFlagL0 and predFlagL1 as outputs. 2. The decoding process for inter sample prediction as specified in subclause 8.5.3.2 is invoked with the luma coding block location ( xC, yC ), the luma prediction block location ( xB, yB ), the luma coding block size block nCS, the luma prediction block width height, nPbW and nPbH, the luma motion vectors mvL0 and mvL1, the chroma motion vectors mvCL0 and mvCL1, the reference indices refIdxL0 and refIdxL1, and the prediction list utilization flags predFlagL0 and predFlagL1 as inputs and the inter prediction samples (predSamples) which are a (nCSL)x(nCSL) array predSamplesL of prediction luma samples and two (nCSC)x(nCSC) arrays predSamplesCr, and predSamplesCr of prediction chroma samples, one for each of the chroma components Cb and Cr as outputs. ... Remove the strings 'the chroma motion vectors mvCL0 and mvCL1, ' from 1. and 2. 8.5.3.1 Derivation process for motion vector components and reference indices: ... Outputs of this process are - luma motion vectors mvL0 and mvL1 - chroma motion vectors mvCL0 and mvCL1, <= Delete this line - reference indices refIdxL0 and refIdxL1, ... Delete the following paragraph: ... When ChromaArrayType is not equal to 0 and predFlagLX (with X being either 0 or 1) is equal to 1, the derivation process for chroma motion vectors in subclause 8.5.3.1.8 is invoked with mvLX and refIdxLX as inputs and the output being mvCLX. ... 8.5.3.1.8 Derivation process for chroma motion vectors: Delete this sub-clause 8.5.3.2 Decoding process for inter prediction samples: ... - luma motion vectors mvL0 and mvL1, - chroma motion vectors mvCL0 and mvCL1, <= Delete this line - reference indices refIdxL0 and refIdxL1, ... ... - The arrays predSamplesLXL, predSamplesLXCb, and predSamplesLXCr are derived by invoking the fractional sample interpolation process specified in subclause 8.5.3.2.2 with the luma locations ( xC, yC ), ( xB, yB ), the width and the height of the current luma prediction block nPbW, nPbH, the motion vectors mvLX, mvCLX, and the reference arrays with refPicLXL, refPicLXCb and refPicLXCr given as input. ... Replace with: ... - The arrays predSamplesLXL, predSamplesLXCb, and predSamplesLXCr are derived by invoking the fractional sample interpolation process specified in subclause 8.5.3.2.2 with the luma locations ( xC, yC ), ( xB, yB ), the width and the height of the current luma prediction block nPbW, nPbH, the motion vector mvLX, and the reference arrays with refPicLXL, refPicLXCb and refPicLXCr given as input. ... 8.5.3.2.2 Fractional sample interpolation process: ... - a luma motion vector mvLX given in quarter-luma-sample units, - a chroma motion vector mvCLX given in eighth-chroma-sample units, <= Delete this line - the selected reference picture sample arrays refPicLXL, refPicLXCb, and refPicLXCr. ... Prior to the paragraph beginning with: ""The location ( xP, yP ) given in full-sample units of..."" Insert the following paragraph: ""The luma motion vector mvLX is interpretted as a chroma motion vector specified in eighth-chroma-sample units when ChromaArrayType is equal to 1."" Eqn (8-180): ""xIntC = ( xP / 2 ) + ( mvCLX[ 0 ] >> 3 ) + xC"" Replace with: ""xIntC = ( xP / 2 ) + ( mvLX[ 0 ] >> 3 ) + xC"" Eqn (8-181): ""yIntC = ( yP / 2 ) + ( mvCLX[ 1 ] >> 3 ) + yC"" Replace with: ""yIntC = ( yP / 2 ) + ( mvLX[ 1 ] >> 3 ) + yC"" " crosewarne D10 (L1003) v33 958 POC difference 0 occurs in text of JCTVC-L0030-v3 Text D10 (L1003) v33 enhancement bbross closed 2013-01-18T11:03:11+01:00 2018-01-22T07:11:30+01:00 "According to the discussion on TMVP hook as proposed in JCTVC-L0177, POC difference 0 can never occur in HEVC version 1 and not need to be specified in HEVC version 1. However there is already such a case of POC difference 0 in the current text of JCTVC-L0030-v3. The following sentence in section '''8.5.3.1.8 Derivation process for collocated motion vectors''' – If DiffPicOrderCnt( pic, currPic ) is less than '''or equal to 0''' for every picture pic in every reference picture list of the current slice, mvCol, refIdxCol, and listCol are set equal to mvLXCol[ xPCol ][ yPCol ], refIdxLXCol[ xPCol ][ yPCol ] and LX, respectively with X being the value of X this process is invoked for. should be replaced with – If DiffPicOrderCnt( pic, currPic ) is less than 0 for every picture pic in every reference picture list of the current slice, mvCol, refIdxCol, and listCol are set equal to mvLXCol[ xPCol ][ yPCol ], refIdxLXCol[ xPCol ][ yPCol ] and LX, respectively with X being the value of X this process is invoked for. " sier D10 (L1003) v33 967 9.2.3.2.2 : redundant condition for codIOffset and codIRange Text D10 (L1003) v33 enhancement bbross closed 2013-01-21T15:51:54+01:00 2018-01-22T07:13:49+01:00 "The condition ""the bitstream shall not contain data that result in a value of codIOffset being greater than or equal to codIRange upon completion of this process."" is redundant in 9.2.3.2.2 because : + When the arithmetic decoding engine is initialized in 9.2.1.4, the bitstream shall not contain data that result in a value of codIOffset being equal to 510 or 511. Therefore, codIOffset is smaller than codIRange. + If codIOffset is smaller than codIRange, after each bin decoding in the case of context or bypass and before an eventual renormalization, the new value of codIOffset is smaller than the new value of codIRange by construction. + If codIOffset is smaller than codIRange before the renormalization, the relation remains the same after the renormalization." PhuongNguyen D10 (L1003) v33 1174 Improvement of HEVC ver.1 defect report Text D10 (L1003) v33 enhancement closed 2013-10-11T03:28:45+02:00 2018-01-22T08:36:26+01:00 "The HEVC ver.1 defect report (JCTVC-N1003) introduces the bug fix of CPB removal time derivation as described in JCTVC-N0091. I believe that the new syntax element au_bp_cpb_removal_delay_length_minus1 shall be larger than or equal to au_cpb_removal_delay_length_minus1. So it would be desirable to add the constraint to the au_bp_cpb_removal_delay_length_minus1 description of the defect report. " kchono D10 (L1003) v33 1048 Typo in Text D10 (L1003) v33 defect closed 2013-03-19T15:25:45+01:00 2018-01-22T08:41:44+01:00 "In 8.4.4.2.1 the sentence: ""Output of this process is the ..."" should be changed to: ""Output of this process are the ..."" The same typo appears in JCTVC-L1005_v1-JCTVC-L1003_v23" ewige D10 (L1003) v33 1057 num_long_term_sps Text D10 (L1003) v33 defect weipu closed 2013-04-01T19:50:07+02:00 2018-01-22T08:42:55+01:00 "num_long_term_sps specifies the number of entries in the long-term RPS of the current picture that are derived based *on* the candidate long-term reference pictures specified in the active SPS. The highlighted word ""on"" is missing." weipu D10 (L1003) v33 1084 Table A-3 Text D10 (L1003) v33 defect closed 2013-05-03T09:53:21+02:00 2013-07-28T12:49:38+02:00 "(JCTVC-L1003 V34) In the title of Table A-3, ""4.3"" should be ""4.1"". Note: Ticket #690 (already closed) addresses this issue and it looks like it was once fixed in the previous versions." kazui D10 (L1003) v33 1081 Redundant condition in availability calculation Text D10 (L1003) v33 enhancement closed 2013-05-02T12:21:16+02:00 2018-01-22T08:44:11+01:00 "In ""6.4.2 Derivation process for prediction block availability"" when sameCb is TRUE, the text checks the following conditions: ( nPbW << 1 ) is equal to nCbS, ( nPbH << 1 ) is equal to nCbS, partIdx is equal to 1, ( yCb + nPbH ) is less than or equal to yNbY, ( xCb + nPbW ) is greater than xNbY. These conditions correspond to: The coding block is partitioned into 4 squares The current part is top right The neighbour pixel is below the current part The neighbour pixel is left of the current part However, I believe that the final condition is redundant. The decode process will never try to predict from locations that are directly below the current part. I doubt that this actually requires a change, as the current text is entirely correct, but I have posted this bug in case: 1. Someone may point out that I have misunderstood something and the final condition is important 2. Someone else is similarly confused by this 3. It is felt that it would help to modify the text " peterderivaz D6 (H1003) dG 291 Use of FL binarization for “Decode Bypass” syntax elements Text D6 (H1003) dG defect bbross closed 2012-01-20T02:40:05+01:00 2012-05-03T11:46:28+02:00 "In several instances, the WD text uses the ""FL"" binarization to describe the parsing for fixed-length decode-bypass syntax elements. In the description of the FL binarization, it is specified as least-significant-bin-first order. However, the HM software for these bypass syntax elements codes them in most-significant-bin-first order. See the following HM function: TDecBinCABAC::decodeBinsEP Either the text or the software needs to be changed in these cases. " bheng D6 (H1003) dG 297 Context increment for coeff_abs_level_greater1_flag does not match HM-5.1 Text D6 (H1003) dG defect bbross closed 2012-01-27T05:02:45+01:00 2012-07-14T20:08:04+02:00 "I have noticed what looks like a discrepancy between the draft spec and HM-5.1. It is regarding the context increment derivation of coeff_abs_level_greater1_flag. The spec says the following: - If n is equal to 15 or all previous syntax elements coeff_abs_level_greater1_flag[pos] with pos greater than n are derived to be equal to 0 instead of being explicitly parsed, the following applies. - .... - When the subset i is not the first one to be processed in this subclause, the following applies. - The variable numGreater1 is set equal to the variable numGreater1 that has been derived during the last invocation of subclause 9.3.3.1.1.6 for the syntax element coeff_abs_level_greater2_flag for the subset i + 1. - When (numGreater1 >> 1) is greater than 0, ctxSet is incremented by one as follows. ctxSet = ctxSet + 1 In HM-5.1, the comparison above is done before the downshift (TDecSbac.cpp, line 1937): UInt uiCtxSet = (iSubSet > 0 && eTType==TEXT_LUMA) ? 3 : 0; if( uiNumOne > 0 ) { uiCtxSet++; if(eTType==TEXT_LUMA && uiNumOne > 3) { uiCtxSet++; } } uiNumOne >>= 1; I think this can be fixed in the working draft by simply removing the downshift in the comparison " pieterkapsenberg D6 (H1003) dG 324 Typo in latest WD Text D6 (H1003) dG defect bbross closed 2012-02-15T23:14:25+01:00 2012-02-17T10:33:09+01:00 "Version: JCTVC-H1003_dG Page 70, section 7.4.2.3 This line has a typo: ''scaling_list_dc_coef_minus8[ sizeID – 2 ][ matrixID ] plus 8 specifies the DC value of the scaling list for 16x16 size when sizeID is equal to 2 and specifies the DC value of the scaling list for 32x32 size when sizeID is equal to '''1'''.'' The last part should say 'for 32x32 size when sizeID is equal to 3'. " hellman D6 (H1003) dG 325 Wrong sao_offset range in band offset case Text D6 (H1003) dG defect bbross closed 2012-02-17T01:13:20+01:00 2012-02-17T08:08:29+01:00 "// Bug1 sao_offset[ cIdx ][ rx ][ ry ][ i ] range's description is not correct in band offset case where signed value is needed (corrent in edge offset case). This is related to ""removing sign of SAO offset (JCTVC-H0434)"", while H0434's draft is correct. // Bug2 Table 8 14 – Specification of array bandTable according to bandIdx is not needed anymore " Tomohiro Ikai D6 (H1003) dG 326 Wrong ALF coeff derivation on DC offset removal Text D6 (H1003) dG defect bbross closed 2012-02-17T01:33:52+01:00 2012-06-29T18:27:50+02:00 "It's related to ""removal of ALF DC offset (JCTVC-G445)"". Because DC offset has been removed, the ALF coef derivation using symmetry should be fixed. The attached file has other small editorial fix." Tomohiro Ikai D6 (H1003) dG 340 Motion Vector Prediction cross reference is wrong. Text D6 (H1003) dG defect bbross closed 2012-02-28T16:00:29+01:00 2012-07-04T19:57:54+02:00 "[Version H1003-v21] Section 8.5.2.1 In numbered bullet 3, I believe the cross reference regarding calculation of the MVPredictor should be to 8.5.2.1.5 rather than 8.5.2.1.3. (which is titled Derivation process for combined bi-predictive merging candidates) Trivial point earlier in the same subclause - there is a repeated comma "",,"" in the paragraph ""Otherwise, if PredMode is equal to MODE_INTER""" rikallen D6 (H1003) dI/dJ/dK 428 PPS/SPS parsing dependency on tiles_or_entropy_coding_sync_idc Text D6 (H1003) dI/dJ/dK technical change bbross closed 2012-03-22T13:45:48+01:00 2012-06-13T11:45:05+02:00 "(originally reported by Peisong Chen) There exists a parsing dependence between SPS ans PPS. The SPS syntax element tiles_or_entropy_coding_sync_idc is uses as dependency for PPS syntax elements. This conflicts with our high level syntax design." ksuehring D6 (H1003) dI/dJ/dK 505 NSQT InterTUSplitDirection wrong for chroma blocks Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-27T23:06:42+02:00 2012-06-12T11:38:50+02:00 "When splitting a transform block non-square, resulting chroma blocks seem to use 2-point transform or reside at wrong locations, e.g.: - Splitting a 16x16 transform block into, e.g. 4x16 luma blocks results in 2x8 chroma blocks. - Splitting a 4x16 luma block into 4x4 blocks results in one strangely located 4x4 chroma block" bbross D6 (H1003) dI/dJ/dK 277 Incoherency between HM and WD on intra_chroma_pred_mode Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-01-11T12:18:06+01:00 2012-07-11T09:41:24+02:00 "In WD, intra_chroma_pred_mode syntax element is in prediction_unit() which implies that in case of an intra_NxN PU, there are four intra_chroma_pred_mode. In HM (see TDecEntropy::decodePredInfo), there is only one intra_chroma_pred_mode in such a case. I don't know who is right or wrong... " sirond D6 (H1003) dI/dJ/dK 336 Mismatch of main profile and San Jose decision on E/Slice Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-23T14:46:58+01:00 2012-06-13T11:46:30+02:00 "In San Jose, plenary discussion on the BoG report JCTVC-0738 decided that entropy slice are not allowed in main profile, but current statement in WD text (H1003_dK) is - When tiles_or_entropy_coding_sync_idc is greater than 0, entropy_slice_flag shall be equal to 0. so Entropy Slice are still allowed when single tile is used. Suggested modification by Ye-Kui: Keep the above sentence in the semantics of entropy_slice_flag (since multiple tiles and Entropy Slice have been made mutually exclusive anyway as per JCTVC-H0513), and add the following bullet item in the profile definition: - entropy_slice_flag shall be equal to 0. " felix.henry D6 (H1003) dI/dJ/dK 369 Tables 8.16 and 8.17 in WD6 have mistakes related ALF filter geometry Text D6 (H1003) dI/dJ/dK defect semih esenlik closed 2012-03-01T14:06:12+01:00 2012-06-29T18:27:27+02:00 The proposal JCTVC-H0068 has been implemented both in the HM (HM-5.2-dev-loopfilters branch) and in the Working Draft 6. However there is mismatch in between the software and the CD. Software performs according to the desired effect according to JCTVC-H0068. However CD does not follow the software. Fix is attached. semih.esenlik D6 (H1003) dI/dJ/dK 410 Lossless coding is not guaranteed Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-15T14:40:25+01:00 2012-06-12T12:22:29+02:00 "At the San Jose meeting, lossless coding mode (H0530) and sign bit hiding (H0481) are adopted. In the lossless coding mode, lowest QP value is used to switch to lossless mode for CU's. However, when lossless coding mode is enabled , current design does not anymore guarantees a lossless operation due to sign bit hiding technique. This is because sign bit is not signaled but derived from the magnitude of the levels and some combinations of level and sign are not allowed. Suggested fix: Disable sign bit hiding for the blocks where lossless coding mode is applied." kugur D6 (H1003) dI/dJ/dK 413 Missing condition for Eq. (7-24) in calculation of Log2MinCUDQPSize Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-16T05:24:28+01:00 2012-06-13T11:47:27+02:00 "In the semantics of max_cu_qp_delta_depth, the variable Log2MinCUDQPSize is calculated as in Eq. (7-24) only when max_cu_qp_delta_depth is greater than 0. However, this condition is missing in the current CD text. Suggested fix: add this condition as below. When max_cu_qp_delta_depth>0, the variable Log2MinCUDQPSize specifying the minimum size of coding units that convey cu_qp_delta, is derived as follows. Log2MinCUDQPSize = Log2MaxCUSize − (max_cu_qp_delta_depth − 1) (7-24) In addition, a typo in “Its a requirement of bitstream conformance …” should be replaced by “It is a requirement of bitstream conformance …”. " Haoping Yu D6 (H1003) dI/dJ/dK 452 Wrong 'else if...' for 'if (skip_flag)' in CU syntax Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-30T12:04:13+02:00 2012-05-15T16:06:48+02:00 "The 'else if...' corresponding to in CU syntax table: else if( slice_type != I | | log2CbSize = = Log2MinCbSize ) { is wrong because this would skip the transform coding for CUs with CBSize greater than minmum CbSize in I slices. Consequently it should be replaced by else { The conditions on slice_type and log2CbSize are already taken into account when parsing pred_mode_flag and part_mode." bbross D6 (H1003) dI/dJ/dK 492 Text cleanup of QP prediction / derivation Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-17T03:29:01+02:00 2012-05-15T16:08:18+02:00 "A merged text is prepared for the following tickets: Ticket 441 Ticket 463 Ticket 465 " kchono D6 (H1003) dI/dJ/dK 496 Long-term picture variable PocLtCurr is set incorrectly when delta_poc_msb_present_flag==1 Text D6 (H1003) dI/dJ/dK defect rickard closed 2012-04-20T15:17:11+02:00 2012-06-13T11:48:19+02:00 "Current decoding process for reference picture set contains the following: for( i = 0, j = 0, k = 0; i < num_long_term_pics; i++ ) if( delta_poc_msb_present_flag[ i ] ) if( used_by_curr_pic_lt_flag[ i ] ) PocLtCurr[ j++ ] = ( ( PicOrderCntVal - DeltaPocLt[ i ] + MaxPicOrderCntLsb ) % MaxPicOrderCntLsb ) - ( DeltaPocMSBCycleLt[ i ] )* MaxPicOrderCntLsb else PocLtFoll[ k++ ] = ( ( PicOrderCntVal - DeltaPocLt[ i ] + MaxPicOrderCntLsb ) % MaxPicOrderCntLsb ) - ( DeltaPocMSBCycleLt[ i ] ) * MaxPicOrderCntLsb Later PocLtCurr[ i ] is compared with PicOrderCntVal. The decoding process text for reference picture sets should be changed to: for( i = 0, j = 0, k = 0; i < num_long_term_pics; i++ ) if( delta_poc_msb_present_flag[ i ] ) if( used_by_curr_pic_lt_flag[ i ] ) PocLtCurr[ j++ ] = PicOrderCntVal - DeltaPocLt[ i ] - DeltaPocMSBCycleLt[ i ] * MaxPicOrderCntLsb else PocLtFoll[ k++ ] = PicOrderCntVal - DeltaPocLt[ i ] - DeltaPocMSBCycleLt[ i ] * MaxPicOrderCntLsb " rickard D6 (H1003) dI/dJ/dK 504 SAO process issues Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-27T11:22:24+02:00 2012-06-11T22:29:49+02:00 "The following issues are present in the SAO process (8.7.2): 1.) in ""8.7.2 Sample adaptive offset process"" - the coding treeblock location ( 0, 0 ) and the largest CU location ( 0, 0 ) are redundant 2.) in ""8.7.2.1 Modification process for sample adaptive offset"" - again (rx,ry) and (x0,y0) are redundant - largest CUs should be CTBs - largest coding unit should be CTB - ""saoWidthInCTB"" should be ""saoWidthInCTBs"", same for Height - variable saoDepth not defined here 3.) in ""8.7.2.1.1 Modification process for luma and chroma samples"" - again xC,yC and rx, ry are redundant - saoTypeIdx 1-4 o edgeIdx derivation in 2. and 3. can be combined o loop over CTB samples i.j is missing in 1.-3. (edgeIdx derivation) o loop over component k is missing in 3. (boundary handling) o in 2. (edgeIdx derivation), edgeIdx can only take the values 0, 2 and 4 since Sign(x) returns just 1 and -1. o in 4. (no SAO for PCM…) edgeTable not needed - saoTypeIdx 5 o repeated comma after otherwise o 1. and 2. can be combined to ""1. The variable bandShift is derived as follows…"" - saoTypeIdx 0 case can be combined with PCM/QP_Y=0 because they all do not apply SAO 4.) In general the process names/headings can be changed to be more meaningful and ""8.7.2.1 Modification process for sample adaptive offset"" and ""8.7.2.1.1 Modification process for luma and chroma samples"" can be combined since the first just loops over all CTBs for one color component." bbross D6 (H1003) dI/dJ/dK 506 Derivation depending on InterTUSplitDirection Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-28T11:13:56+02:00 2012-06-12T11:39:00+02:00 "Both process where InterTUSplitDirection are not identical while they should and missing something: ""8.5.3.1 Decoding process for luma residual blocks"" yB1 and xB2 derivation are missing ""8.7.1.1 Derivation process of transform unit boundary"" – The variable yB1 is set equal to yB + ( ( 1 << log2TrafoHeight ) >> 1 ) should be – The variable yB2 is set equal to yB + ( ( 1 << log2TrafoHeight ) >> 1 ) To avoid mismatches, one process should be defined that is called in both places." bbross D6 (H1003) dI/dJ/dK 521 """max_dec_pic_buffering"" without index is not defined." Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-04T13:08:13+02:00 2012-06-13T11:48:39+02:00 "max_dec_pic_buffering[ i ] sometimes appears with its index ""[ i ]"" and sometimes without it. Annex A. A4.1 Annex C C.3.1, C.4 and C.5.2 Replace max_dec_pic_buffering by max_dec_pic_buffering[ max_temporal_layers_minus1 ] " sasai D6 (H1003) dI/dJ/dK 522 The description of DPB size for temporal layer is unclear. Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-04T13:10:50+02:00 2012-11-30T15:42:16+01:00 "The description of DPB size for temporal layer is unclear. Annex C.1, C.5.2, and C.5.2.1 Decrease the values of MaxDpbSize in Table A-1 by one, or remove the ""+ 1"" in the application of the max_dec_pic_buffering[ i ] constraint. Replace The DPB size (number of picture storage buffers) for temporal layer X is max_dec_pic_buffering[ X ] + 1 for each X in the range of 0 to max_temporal_layers_minus1, inclusive. by The DPB size (number of picture storage buffers) for decoding temporal layer X is max_dec_pic_buffering[ X ] for each X in the range of 0 to max_temporal_layers_minus1, inclusive. " sasai D6 (H1003) dI/dJ/dK 523 "There is inconsistency in the naming of ""max_dec_pic_buffering""." Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-04T13:18:58+02:00 2012-11-30T15:42:16+01:00 "At 7.4.2.1 The relationship between max_dec_pic_buffering[ i ] and max_dec_pic_buffering[ i-1 ] is not defined." sasai D6 (H1003) dI/dJ/dK 391 Slice header not parsable (slice_address) Text D6 (H1003) dI/dJ/dK technical change bbross closed 2012-03-07T18:05:12+01:00 2012-06-13T11:46:56+02:00 "From the semantics: The length of the slice_address syntax element is ( Ceil( Log2( PicWidthInCtbs * PicHeightInCtbs ) ) + SliceGranularity ) bits. using PicWidthInCtbs = Ceil( pic_width_in_luma_samples ÷ ( 1 << Log2CtbSize ) ) (7 14) PicHeightInCtbs = Ceil( pic_height_in_luma_samples ÷ ( 1 << Log2CtbSize ) ) (7 15) The syntax elements pic_width_in_luma_samples and pic_height_in_luma_samples are coded in the SPS. When parsing a slice header the decoder can determine the proper SPS only by activating the PPS using the syntax element pic_parameter_set_id. According to the syntax table pic_parameter_set_id is parsed AFTER slice_address." ksuehring D6 (H1003) dI/dJ/dK 329 (Actual Version: H1003_dK): Typos and wrong constraint in max_cu_qp_delta_depth Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-17T20:38:02+01:00 2012-06-13T11:53:19+02:00 "Page 66: max_cu_qp_delta_depth. First sentence: should be coding units, not coding unit. Second sentence: Its should be It's (picky) I believe the last sentence should be removed, as it restates the requirement in the second sentence, but it does so much less precisely (uses should rather than shall, and doesn't give an exact definition). " hellman D6 (H1003) dI/dJ/dK 330 (Actual version: H1003_dK) Decoding process for intra blocks incorrect for chroma Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-18T00:02:54+01:00 2012-07-14T20:08:02+02:00 "When subclause 8.4.3 is invoked for decoding intra chroma blocks, the inputs (xB,yB) indicate the location of the current block in chroma pixels. However, the split_transform_flag[xB][yB][trafoDepth] are defined at luma locations, not at chroma locations. So the locations of the split flags being used here for chroma decoding are going to be off by a factor of 2. Also, subclause 8.4.3 does not appear to check whether the chroma is already at the 4x4 level before splitting it further. If the luma TU was split down to 4x4, this subclause will currently split chroma down to 2x2 as well. " bheng D6 (H1003) dI/dJ/dK 331 No constraint on tiles+slices Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-20T15:20:50+01:00 2012-06-13T11:53:39+02:00 "Section 6.3 (para 4) does not contain the text from JCTVC-H0737 concerning the combination of tiles+slices (as of version _dK): A tile may comprise treeblocks contained in more than one slice subject to the constraint that all coded blocks in each slice belong to the tile. Similarly, a slice may comprise treeblocks contained in several tiles subject to the constraint that all coded blocks in each tile belong to the slice." thomasd D6 (H1003) dI/dJ/dK 332 "Numerous references to ""macroblock""" Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-20T15:25:25+01:00 2012-06-13T11:53:58+02:00 "A number of concepts are still defined in terms of a ""macroblock"". (Actual version _dK)." thomasd D6 (H1003) dI/dJ/dK 333 Minor text errors Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-20T15:32:46+01:00 2012-06-13T11:54:36+02:00 "(Actual version _dK) Section 6.5.2 does not appear in the contents 6.6 incorrectly references 6.5.1 instead of 6.5.3 7.4.10 Residual coding semantics. Paras 3, 4, 5, 6 should all begin “... specifies ...” (singular) not “... specify..” (plural) as per significant_coeff_group_flag (para 7) 7.4.10 para 2 incorrectly references 6.5.1 instead of 6.6" thomasd D6 (H1003) dI/dJ/dK 339 Out of bounds index computation in Angular Intra prediction Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-28T08:57:16+01:00 2012-07-14T20:08:03+02:00 "In the WD, subclause 8.4.3.1.6 ""Specification of Intra_Angular (2..9, 11..25, 27..34) prediction mode"" the following equation is shown (8-48): refMain[ x ] = p[ −1, −1+( ( x*invAngle+128 )>>8 ) ], with x=( nS*intraPredAngle ) >>5..−1 For the case of an intra 4x4 block with an intra mode of 25, intraPredAngle is -2 and invAngle is -4096 (table 8-5 and 8-6). Then, the index range goes from (4*-2)>>1 .. -1, which is -1..-1. This implies that the equation is applied once, with x = -1. In that case we index array p with [-1,-1+((-1*-4096+128)>>8)] = [-1,15]. However, array P is specified to be sized from [-1..2*ns-1,-1..2*ns-1], [-1..7,-1..7] in this case. HM seems to avoid this by just skipping the loop altogether, since it has the following code: {{{ Int invAngleSum = 128; // rounding for (shift by 8) for (k=-1; k>blkSize*intraPredAngle>>5; k--) { invAngleSum += invAngle; refMain[k] = refSide[invAngleSum>>8]; } }}} In this case, the exit condition is met immediately, since k is not larger than -1 (it is equal to -1). If the HM model followed the WD exactly, the loop exit condition would have been a great-or-equal operator like so: {{{ for (k=-1; k>=blkSize*intraPredAngle>>5; k--) }}} " pieterkapsenberg D6 (H1003) dI/dJ/dK 341 Clipping value for scaled motion vector predictor is not appropriate Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T03:56:31+01:00 2012-07-04T19:57:54+02:00 "In JCTVC-H1003_dK, motion vector is treated as an integer value even though it sometimes shows half or quarter pel position. However, a scaled motion vector is treated as a floating value in expression (8-138), (8-146) and (8-156). It should be modified to integer value such as below. And, there is one typo in expression (8-146) (mvLXA should be replaced with mvLXB). ---------------------------- expression (8-138) >original mvLXA = Clip3( -8192, 8191.75, Sign( DistScaleFactor * mvLXA ) * ( (Abs( DistScaleFactor * mvLXA ) + 127 ) >> 8 ) ) (8-138) >modified mvLXA = Clip3( -32768, 32767, Sign( DistScaleFactor * mvLXA ) * ( (Abs( DistScaleFactor * mvLXA ) + 127 ) >> 8 ) ) (8-138) expression (8-146) >original mvLXB =Clip3( -8192, 8191.75, Sign( DistScaleFactor * mvLXA ) * ( (Abs( DistScaleFactor * mvLXA ) + 127 ) >> 8 ) ) (8-146) >modified mvLXB =Clip3( -32768, 32767, Sign( DistScaleFactor * mvLXB ) * ( (Abs( DistScaleFactor * mvLXB ) + 127 ) >> 8 ) ) (8-146) expression (8-156) >original mvLXCol = Clip3( -8192, 8191.75, Sign( DistScaleFactor * mvCol ) * ( (Abs( DistScaleFactor * mvCol ) + 127 ) >> 8 ) ) (8-156) >modified mvLXCol = Clip3( -32768, 32767, Sign( DistScaleFactor * mvCol ) * ( (Abs( DistScaleFactor * mvCol ) + 127 ) >> 8 ) ) (8-156) ---------------------------- " ToshiyasuSugio D6 (H1003) dI/dJ/dK 343 Syntax table description Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T06:56:28+01:00 2012-06-29T18:41:56+02:00 "(actual version dK) 5.9 Each syntax element is described by its name (all lower case letters with underscore characters), its one or two syntax categories, and one or two descriptors for its method of coded representation. In HEVC, we do not have syntax category now and there is only one descriptor." libin D6 (H1003) dI/dJ/dK 344 PPS syntax Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T06:58:58+01:00 2012-06-13T11:54:54+02:00 "(actual version dK) 7.3.2.2 if(slice_type = =P | | slice_type = = B) log2_parallel_merge_level_minus2 ue(v) This is PPS level syntax, and the slcie_type is unknown." libin D6 (H1003) dI/dJ/dK 345 CtbAddr update at slice data syntax Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:03:11+01:00 2012-06-12T15:10:18+02:00 "(actual version dK) 7.3.4 CtbAddrTS++ Only CtbAddrTS is increased, CtbAddrRS should also be updated. It should be something like CtbAddrRS=CtbAddrTStoRS[ CtbAddrTS ], whereas the array CtbAddrTStoRS needs to be defined." libin D6 (H1003) dI/dJ/dK 346 PCM alignment at PU syntax Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:05:26+01:00 2012-06-13T11:56:02+02:00 "(actual version dK) 7.3.7 while( !byte_aligned( ) ) pcm_alignment_zero_bit u(v) f(1) should be used instead of u(v)." libin D6 (H1003) dI/dJ/dK 347 non-break hyphen and minus Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:07:38+01:00 2012-06-13T11:56:40+02:00 "(actual version dK) 7.3.7.2 NumPCMBlock-- Minus should be used instead of non-break hyphen." libin D6 (H1003) dI/dJ/dK 348 Log2MaxTrafoSize constraint Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:09:43+01:00 2012-05-15T16:05:32+02:00 "(actual version dK) 7.4.2.1 log2_diff_max_min_transform_block_size specifies the difference between the maximum and minimum transform size. The variable Log2MaxTrafoSize is set equal to log2_min_transform_block_size_minus 2 + 2 + log2_diff_max_min_transform_block_size. The bitstream shall not contain data that result in Log2MaxTrafoSize greater than Log2CtbSize. The last sentence should be changed to The bitstream shall not contain data that result in Log2MaxTrafoSize greater than Min( Log2CtbSize, 5 ). " libin D6 (H1003) dI/dJ/dK 350 on alf_coef_in_slice_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:21:06+01:00 2012-06-29T18:28:28+02:00 "(actual version dK) 7.4.2.1 alf_coef_in_slice_flag equal to 1 specifies that the ALF parameters alf_param() are present in the slice header; equal to 0 specifies that the ALF parameters alf_param() are not present in the APS. This second part is probably a copy paste error and should be changed to “equal to 0 specifies that the ALF parameters alf_param() are present in the APS.” (delete not)" libin D6 (H1003) dI/dJ/dK 351 on shared_pps_info_enabled_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:23:06+01:00 2012-06-13T11:57:07+02:00 "(actual version dK) 7.4.2.2 shared_pps_info_enabled_flag specifies the shared information in picture parameter set RBSP shall be used for the referred slices. If shared_pps_info_enabled_flag is equal to 1, the alf_param() in picture parameter set RBSP shall be applied for the referred slices; otherwise, the alf_param() in slice header(s) shall be applied. This is a leftover from pre-APS times, the syntax element was deleted due to F747 APS adoption in WD4 d6 (JCTVC-F803_d6.doc). Consequently the semantics can be removed as well. " libin D6 (H1003) dI/dJ/dK 352 on num_ref_idx_active_override_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:25:40+01:00 2012-06-13T11:57:34+02:00 "(actual version dK) 7.4.3 num_ref_idx_active_override_flag equal to 1 specifies that the syntax element num_ref_idx_l0_active_minus1 is present for P and B slices and that the syntax element num_ref_idx_l1_active_minus1 is present for B slices. num_ref_idx_active_override_flag equal to 0 specifies that the syntax elements num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1 are not present. When the current slice is a P or B slice and field_pic_flag is equal to 0 and the value of num_ref_idx_l0_default_active_minus1 in the picture parameter set exceeds 15, num_ref_idx_active_override_flag shall be equal to 1. When the current slice is a B slice and field_pic_flag is equal to 0 and the value of num_ref_idx_l1_default_active_minus1 in the picture parameter set exceeds 15, num_ref_idx_active_override_flag shall be equal to 1. The description of the last two paragraphs depends on field_pic_flag, which we do not have in HEVC. This needs to be removed." libin D6 (H1003) dI/dJ/dK 353 on beta_offset_div2 and tc_offset_div2 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:27:03+01:00 2012-06-11T22:30:24+02:00 "(actual version dK) 7.4.3 beta_offset_div2 and tc_offset_div2 specify deblocking parameter offsets for tC and β (divided by 2). The order of tC and β should be changed to match the previous order." libin D6 (H1003) dI/dJ/dK 354 on five_minus_max_num_merge_cand Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:30:23+01:00 2012-07-04T19:57:54+02:00 "(actual version dK) 7.4.3 five_minus_max_num_merge_cand specifies the maximum number of merging MVP candidates supported in the slice subtracted from 5. The maximum number of merging MVP candidates, MaxNumMergeCand is computed as MaxNumMergeCand = 5 − five_minus_max_num_merge_cand The value of five_minus_max_num_merge_cand shall be limited such that MaxNumMergeCand is in the range of 0 to 5, inclusive. Can MaxNumMergeCand be 0? The last sentence should be changed to such that MaxNumMergeCand is in the range of 1 to 5, inclusive." libin D6 (H1003) dI/dJ/dK 355 on skip_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:32:30+01:00 2012-06-13T11:58:10+02:00 "(actual version dK) 7.4.3 skip_flag[ x0 ][ y0 ] equal to 1 specifies that for the current coding unit, when decoding a P or B slice, no more syntax elements except the motion vector predictor indices are parsed after skip_flag[ x0 ][ y0 ]. ""motion vector predictor indices"" should be ""merging candidate index""." libin D6 (H1003) dI/dJ/dK 356 PCM semantics Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:33:51+01:00 2012-07-11T11:13:18+02:00 "(actual version dK) The semantics relating to PCM should be moved to the PU semantics part." libin D6 (H1003) dI/dJ/dK 357 on ref_idx_l0 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:37:19+01:00 2012-06-12T15:31:55+02:00 "(actual version dK) 7.4.7 ref_idx_l0[ x0 ][ y0 ] specifies the list 0 reference picture index for the current prediction unit. The array indices x0, y0 specify the location ( x0, y0 ) of the top-left luma sample of the considered prediction block relative to the top-left luma sample of the picture. When ref_idx_l0[ x0 ][ y0 ] is not present and combined_inter_pred_ref_idx is present, ref_idx_l0[ x0 ][ y0 ] is inferred to be equal to ( ( combined_inter_pred_ref_idx – NumPredRefLC ) / NumPredRefL1 ). This is a leftover from CAVLC. The whole last sentence “When…” can be removed." libin D6 (H1003) dI/dJ/dK 358 on SP Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:38:29+01:00 2012-04-28T15:07:00+02:00 "(actual version dK) 8.1 At the beginning of the decoding process for each P, SP, or B slice, I guess we do not have SP slice in HEVC. There are also some other SPs elsewhere." libin D6 (H1003) dI/dJ/dK 359 on POC usage Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:40:16+01:00 2012-06-13T11:58:27+02:00 "(actual version dK) 8.3.1 Picture order counts are used to identify pictures, for deriving motion parameters in temporal or spatial direct mode, ""temporal or spatial direct mode"" should be ""inter prediction and merge mode""." libin D6 (H1003) dI/dJ/dK 360 on IntraPredMode Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:52:49+01:00 2012-07-14T20:08:02+02:00 "(actual version dK) 8.4.1 For N being either replaced A or B, the variables intraPredModeN are derived as follows. ...... – Otherwise, if yB−1 is less than yCtb, intraPredModeA is set equal to IntraPredMode[ xBA ][ yBA ] and intraPredModeB is set equal to Intra_DC. ...... I suggest changing the last sentence to Otherwise, if yB−1 is less than yCtb, intraPredModeB is set equal to Intra_DC." libin D6 (H1003) dI/dJ/dK 361 decoding process of AMP Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T07:53:45+01:00 2012-06-12T15:10:45+02:00 "(actual version dK) 8.5.1 The decoding processes of AMP are not specified." libin D6 (H1003) dI/dJ/dK 362 Wrong constraint on Tile in Main profile Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T08:14:45+01:00 2012-06-13T11:59:05+02:00 "(Actual version: H1003_dK) According to the plenary discussion at the San Jose meeting and JCTVC-H0738 (WG11 m24000), A.3.2 Main profile: ... – When tiles_or_entropy_coding_sync_idc is equal to 1, ColumnWidthInLumaSamples[ i ] shall be '''less''' than or equal to 384 for any i in the range of 0 to num_tile_columns_minus1, inclusive. should be – When tiles_or_entropy_coding_sync_idc is equal to 1, ColumnWidthInLumaSamples[ i ] shall be '''greater''' than or equal to 384 for any i in the range of 0 to num_tile_columns_minus1, inclusive. " hao D6 (H1003) dI/dJ/dK 363 Incorrect table for invAngle in 8.4.3.1.6 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-02-29T11:36:13+01:00 2012-07-14T20:08:04+02:00 "(Actual version _dK) The table for invAngle does not define it for all the cases where intraPredAngle < 0 and instead defines it for some other cases where it is not needed. Revised table and some other minor corrections attached." thomasd D6 (H1003) dI/dJ/dK 365 on enable_temporal_mvp_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-01T02:36:44+01:00 2012-06-13T11:59:55+02:00 "(actual version dK) 7.4.2.2 enable_temporal_mvp_flag enable_temporal_mvp_flag equal to 0 together with temporal_id equal to 0 also indicates that the marking process will occur before decoding the first picture with an output order greater than the current non-TMVP picture. should be enable_temporal_mvp_flag equal to 0 together with temporal_id equal to 0 also indicates that the marking process will occur before decoding the current non-TMVP picture. to match the decoding process specified in 8.3.5." libin D6 (H1003) dI/dJ/dK 367 sao_type_idx binarization Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-01T09:58:34+01:00 2012-06-11T22:31:13+02:00 sao_type_idx should be unary binarization instead of fix-length binarization when using CABAC chihming.fu D6 (H1003) dI/dJ/dK 373 ALF: alfRun, luma filter index derivation, and chroma filtering process Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-02T04:02:31+01:00 2012-06-29T18:29:35+02:00 "1. alfRun update in 7.3.3.5. An editing error about update mechanism of alfRun. 2. luma filter index derivation in 8.7.3.3. The derivation description of G609 is missed. 3. chroma filtering process in 8.7.3.5 An copy-paste editing error. " chiayang_tsai D6 (H1003) dI/dJ/dK 374 An editing error about update mechanism of saoRun Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-02T08:44:53+01:00 2012-06-11T22:31:59+02:00 An editing error about update mechanism of saoRun chihming.fu D6 (H1003) dI/dJ/dK 376 section 6.5.1 raster order to tile scan order Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-02T16:48:28+01:00 2012-06-11T22:32:26+02:00 "(From version dk) In 6.5.1, an array CtbAddrTS[] is defined, seemingly for conversion of raster scan to tile scan order. In the slice data syntax tables, an undefined array is referenced: CtbAddrRStoTS. It looks like the array in 6.5.1 (CtbAddrTS) and CtbAddrRStoTS might be the same, and their names should be aligned. Note that CtbAddrTS is widely referenced elsewhere as a variable, rather than an array. Also, the definition of the raster scan to tile scan array in 6.5.1 does not look correct, and needs checking. " stworrall D6 (H1003) dI/dJ/dK 377 Intra LM mode offset equation is incorrect Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-02T18:26:14+01:00 2012-07-12T15:00:52+02:00 "In the derivation of the linear offset ""b"" in LM intra mode, the CD shows the following equation (8-75): b = ( L – ( ( a*C ) >> k1 ) + ( 1 << ( k2 − 1 ) ) ) >> k2 This is incorrect and does not match HM, L and C should be swapped: b = ( C – ( ( a*L ) >> k1 ) + ( 1 << ( k2 − 1 ) ) ) >> k2" pieterkapsenberg D6 (H1003) dI/dJ/dK 378 Several typos in WD Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-03T02:44:05+01:00 2012-06-29T18:29:54+02:00 "(Actual version dK) Several typos in WD: 1. P. 97, Equation 8-11, RefPicList0 should be RefPicList1 2. P. 96, 8.3.3.2: ""When this process is invoked, a unavailable reference picture is generated as follows"". ""a"" should be ""an"". 3. P.6 3.72 missing definition for ""picture"" " junxu D6 (H1003) dI/dJ/dK 383 (Actual version: D6 dK) Typo in part_mode sematics Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-05T23:29:02+01:00 2012-07-04T19:57:55+02:00 "Section 7.4.6 Coding unit semantics, part_mode definition Third sub-bullet says: Otherwise (log2CbSize is greater than 3 or inter_4x4_enabled_flag is equal to q), The 'q' should be a '1'. " hellman D6 (H1003) dI/dJ/dK 384 Context increment for coeff_abs_level_greater1_flag and coeff_abs_level_greater2_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-06T04:26:43+01:00 2012-07-14T20:08:04+02:00 "Actually in dK version. Context increment for coeff_abs_level_greater1_flag and coeff_abs_level_greater2_flag is not accurately derived in specification according to the adoption of high throughput proposal. The bug can be fixed by doing, 1) Add variant numGreater1 in 7.3.10 residual_coding () syntax table and update it. 2) Remove derivation and update process of variant numGreater1 in 9.2.3.1.5 and 9.2.3.1.6 Attached is text modification in related sections. " cjlsnow D6 (H1003) dI/dJ/dK 385 cuDepth typos Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-06T16:03:11+01:00 2012-06-13T12:00:20+02:00 replace 9 occurrences of cuDepth by cbDepth bbross D6 (H1003) dI/dJ/dK 388 scaling_list_dc_pred_mode_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-07T00:47:10+01:00 2012-06-13T12:00:31+02:00 "scaling_list_dc_pred_mode_flag exists in semantics section only (i.e. in 7.4.2.3). Needs to be removed? " madhukar D6 (H1003) dI/dJ/dK 396 on usage of combCnt Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-09T06:03:03+01:00 2012-07-04T19:57:55+02:00 "(actual version dK) Similar to ticket #395, combCnt in 8.5.2.1.3 is not necessary." libin D6 (H1003) dI/dJ/dK 403 non_square_quadtree_enabled_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-14T18:06:46+01:00 2012-05-15T16:06:30+02:00 non_square_quadtree_enabled_flag is defined at section 7.3.2.1. But NSQT can not be really switched off when non_square_quadtree_enabled_flag is set to 0. xzheng D6 (H1003) dI/dJ/dK 404 Section 8.4.3.1.2 (in H1003_dK version) Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-14T19:26:25+01:00 2012-07-14T20:08:02+02:00 "Smoothing defined in Section 8.4.3.1.2 is getting applied to Intra_FromLuma mode (which has its own separately defined smoothing before downsampling in Section 8.4.3.1.8). I believe HM6 and earlier versions of HM do not apply this smoothing for Intra_FromLuma mode. Fix: Change bullet 2 in 8.4.3.1.2 to: 2. If intraPredMode is equal to Intra_DC *or Intra_FromLuma*, intraFilterType[ nS ][ IntraPredMode ] is set equal to 0. " madhukar D6 (H1003) dI/dJ/dK 408 scaling_list_dc_coef_minus8 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-15T10:58:47+01:00 2012-06-13T12:01:02+02:00 The semantics of scaling_list_dc_coef_minus8 should be moved to 7.4.2.4 from 7.4.2.3. And the semantics of its default value is inconsistent with HM6 software. The default value should be 16. teruhiko D6 (H1003) dI/dJ/dK 409 scaling_list_enable_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-15T11:01:24+01:00 2012-03-15T15:06:28+01:00 "(actual version id H1003_dK) The descriptor of scaling_list_enable_flag is missing in 7.3.2.1. Add ""u(1)"" in descriptor filed." teruhiko D6 (H1003) dI/dJ/dK 412 Deblocking processing order in Draft Text does not match HM Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-16T01:33:11+01:00 2012-06-01T22:30:29+02:00 The draft text specifies that for each CU in coding order (I assume this means the leaf CU, not the largest CU), first all vertical edges are filtered, then all horizontal edges are filtered. HM6.0 does all vertical edges for the whole picture first, then all horizontal edges for the whole picture. This is a different data dependency. For HM, all vertical edges use pre-deblocked pixels as input, whereas the draft spec suggests that the vertical filters may sometime use horizontally deblocked pixels as inputs. Which one is correct/intended? A picture-based ordering has buffer implications for hardware implementations. pieterkapsenberg D6 (H1003) dI/dJ/dK 416 Duplicate equations in 8.5.2.2.3.1/2 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-19T03:20:33+01:00 2012-07-04T19:57:55+02:00 "Equation (8-214) defines how to average 2 motion-compensated predictions. Equation (8-213) is a non-normative simplification of (8-214), which essentially rewrites (x+y)/2 as x if it is known that x=y. Since (8-213) does not introduce any normative behavior it should be removed. The same applies to (8-219) w.r.t. (8-220). " fbossen D6 (H1003) dI/dJ/dK 417 Subclause 8.4 wording, typos, formatting Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-19T13:32:46+01:00 2012-07-14T20:08:04+02:00 "Wording: ""Output of this process is"" --> ""Output of this process are"", if more than one thing is output (like samples) Subclause 8.4.1: - p.99: 0,1,2,..,35 --> 0..35 - Figure 8-1: The directions do not match the directions in Figure 8-2. Harmonize, merge the figures? - p.101: in step 6.2)i.: ""IntraPredMode[ xB ][ yB ] = rem_intra_luma_pred_mode"" --> ""IntraPredMode[ xB ][ yB ] = rem_intra_luma_pred_mode[ xB ][ yB ]"" Subclause 8.4.2: - Syntax elements are available and do not need to be input to the process (intra_chroma_pred_mode, chroma_pred_from_luma_enabled_flag), intra_chroma_pred_mode --> intra_chroma_pred_mode[ xB ][ yB ] - Table 8-2: ""LM"" is not specified, supposedly mode 35, Intra_FromLuma Subclause 8.4.3.1: Notation ""2x"" --> ""2*x"", for y accordingly. Subclause 8.4.3.1.2: - The specified threshold intraHorVerDistThresh[nS]=10 for nS=4 and nS=64 implies that minDistVerHor is never larger than the threshold. Rephrase step 3 to make this evident? Subclause 8.4.3.1.5: - ""with x, y = 0..nS−1"" is obsolete in eq. (8-41) - Eqs.(8-42)-(8-44): ""1*"" could be removed for clarity. - Figure 8-2 misses the numbering of the prediction modes. Subclause 8.4.3.1.6: - The prediction is specified with refMain at the top of the current block. The presentation would be clearer if the text for horizontal and vertical directions would be separated around eqs(8-55,56). This would make the swapping operation at the end obsolete. (The variable name 'refMain' seems to be left over from the proposal, rename?) - Table 8-5: horizontal double line between 2nd and 3rd row to make content more clear. Make formatting of numbers consistent. - Table 8-6: horizontal double line between 2nd and 3rd row to make content more clear. Make formatting of numbers consistent with Table 8-5. - Text before eq.(8-50): ""Otherwise"" --> ""- Otherwise"" - Text before eq.(8-53): ""by the following procedures"" --> ""by the following ordered steps"" - If the swapping operation is kept in the text, it should be specified more precisely and start with a ""when"" instead of an ""if"". Subclause 8.4.3.1.7: - ""This intra prediction mode is invoked when intraPredMode is equal to 34."" --> the mode number is 0. - Text around eq.(8-57): ""x, y = 0..nS−1"" is doubled, the one after the equation should be deleted, spec of variable k put to text above. Subclause 8.4.3.1.8: - Notation ""2x"" --> ""2*x"", for y accordingly. - Notation of variables p* with italics in eqs (8-62)-(8-65), non-italics elsewhere. " mwi D6 (H1003) dI/dJ/dK 418 refernce picture list construction Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-20T05:04:37+01:00 2012-05-18T12:24:12+02:00 "in JCTVC-H1003dK, a typo is found in equation 8-11 When the slice is a B slice, the list RefPicList1 is constructed as follows: for( cIdx = 0; cIdX ≤ num_ref_idx_l1_active_minus1; cIdx++) (8 11) RefPicList0[ cIdx ] = ref_pic_list_modification_flag_l1 ? RefPicListTemp1[ list_entry_l1[ cIdx ] ] : RefPicListTemp1[ cIdx ] Where RefPicList0[cIdx] shall be RefPicList1[cIdx]." eeehey D6 (H1003) dI/dJ/dK 423 Syntax Elements ctxIdxTable is inconsistent with Syntax in Tablular form Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-22T02:30:43+01:00 2012-07-11T11:06:25+02:00 "Example: rem_intra_pred_mode is list as ae(v) in the prediction unit syntax table, but is listed as using the decode bypass method in the table entitled ""Syntax elements and associated types of binarization, maxBinIdxCtx, ctxIdxTable, and ctxIdxOffset"". In the HM5 code, the bits are being encoded via encodeBinsEP (equiprobable mode)." rkaliski D6 (H1003) dI/dJ/dK 424 The position of DF vertical edge is incorrect in 8.7.1.4. Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-22T03:24:16+01:00 2012-06-12T16:12:16+02:00 "4.For xDk set equal to xC+( k << 2 ), k=0..nD*2 − 1, the following applies: –For yDm set equal to yC+( m << 3 ), m=0..nD − 1, the following ordered steps apply: ...... 5.For yDm set equal to yC+( m << 3 ), m=0..nD − 1, the following applies: –For xDk set equal to xC + ( k << 2 ), k = 0..nD*2 - 1, the following ordered steps apply: In 8.7.1.4 process 4 is related to vertical edge and process 5 is related to horizontal edge. However yDk and yDm are same between vertical edge and horizontal edge. I think that position of vertical edge should be changed as following. 4.For xDk set equal to '''xC+( k << 3 ), k=0..nD − 1,''' the following applies: –For yDm set equal to '''yC+( m << 2 ), m=0..nD*2 − 1,''' the following ordered steps apply: ...... 5.For yDm set equal to yC+( m << 3 ), m=0..nD − 1, the following applies: –For xDk set equal to xC + ( k << 2 ), k = 0..nD*2 - 1, the following ordered steps apply: " JiCheonKim D6 (H1003) dI/dJ/dK 431 Missing initial value for candIntraPredModeB and candIntraPredModeA Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-23T07:52:58+01:00 2012-07-14T20:08:04+02:00 "(actual version dK) 8.4.1 ...... 5. The candModeList[ x ] with x=0..2 is derived as follows: – If candIntraPredModeB is equal to candIntraPredModeA, the following applies: ...... candIntraPredModeB and candIntraPredModeA have no initial values, suppose candIntraPredModeN is equal to intraPredModeN but need to be described in text. " Changcai Lai D6 (H1003) dI/dJ/dK 432 Maximum number of slices Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-23T11:52:05+01:00 2012-07-20T11:33:40+02:00 "In A.4.2 a) and b), the constraint for the maximum number of slices per picture uses MaxLumaPR (where MaxMBPS was used in AVC). The result is rather huge, for example 92842 slices for Level 4.2. I guess something like a CU size is missing in the equation." iperroux D6 (H1003) dI/dJ/dK 433 Subclause 8.5 bugs, wording, typos, cross references Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-23T16:18:16+01:00 2012-07-04T19:57:55+02:00 "Subclause 8.5: - Step 2.: The decoding process for the residual signal of coding units in inter prediction mode is Subclause 8.5.3 instead of 8.5.2.2.3.2 Subclause 8.5.1: - wording for inputs: add 'the' between 'specifying' and 'prediction'. (2x) - PartIdx is a local variable and should therefore be written as partIdx. - PartMode is a local variable and should therefore be written as partMode. - For the steps depending on partMode: If the prediction unit size is not the coding unit size, the decoding process for prediction units in inter prediction mode (subclause 8.5.2) should return _modified_ arrays predSample{L,Cb,Cr} since the same array is filled step-by-step. Subclause 8.5.2: - specification of process output: wording/typo semicolon in ""inter prediction samples (predSamples)/;/ which are ..."" Subclause 8.5.2.1: - Local variables should start lower case in second sentence after Input, Output spec: PredFlagL0, PredFlagL1. - Step 3 (after eq (8-94)): The derivation process for luma motion vector prediction is subclause 8.5.2.1.5 (instead of 8.5.2.1.3) (also reported in #340) Subclause 8.5.2.1.1: - In step 3, the size of the current PU (nPSW,nPSH) is missing in the parameter set passed to subclause 8.5.2.1.7 The text in subclause 8.5.2.1.7 indicates the refIdx of the 'current prediction unit partition', while it is the refIdx of A1 or 0. - In step 7, the variable numNscaleMergeCand is not specified Subclause 8.5.2.1.2: - Eqs (8-103)--(8-105) miss a ""("" after the ""="". Same comment for Eqs (8-141)--(8-143). - Harmonize expression for the location of A1 in 8.5.2.1.2 and 8.5.2.1.6 (top/bottom right pixel of PU, respectively) Subclause 8.5.2.1.{3,4}: - Typo ""dervied"" should be ""derived"" before eq.(8-106), (8-115), (8-124) Subclause 8.5.2.1.4: - Remove round brackets in statement ""If (slice_type is equal to P)"" Subclause 8.5.2.1.5: - Step 2.: replace ""subclause 5"" by subclause ""8.5.2.1.7"". Subclause 8.5.2.1.6: - Figure 8-3 should be marked informative. The depicted positions of A1,B1,B2 correspond to the specification of A1,B1,B2 in 8.5.2.1.2, not to specification in this subclause. - Step 1 for mvLXA: Remove the sentence ""The set of sample locations ( xAk, yAk ) represent the sample locations immediately to the left side of the left partition boundary and it’s extended line."" - Step 2 for mvLXA: rephrase, remove 'initially'. - Steps 4,5 for mvLXA: repeated specification of yA1, remove this. Subclause 8.5.2.1.{6,7}: - scaling motion vectors according to POC is specified three times, around eqs. (8-137),(8-145), and (8-155). --> Put into separate process. - Eq.(8-138,146,156): Fractional maximum MV length 8191.75? all other values are integer. (also ticket #341) Subclause 8.5.2.2.1 ""Reference picture selection process"" is not specified. Subclause 8.5.2.2.2: - remove 'general' in ""These variables are used only inside this subclause for specifying general fractional-sample locations inside the reference sample arrays ..."" - Replace ""0<=xL Log2MinTrafoSize )''' by '''if( firstChromaCbf | | log2TrafoSize > 2 )''' in transform_tree syntax Replace '''Log2MinTrafoSize + 1''' by '''3''' in InterTUSplitDirection derivation (4x)__ __[Issue 3]__ The residual_coding syntax for chroma is called with the variable log2TrafoSizeC as input although it requires log2TrafoWidthC and log2TrafoHeightC. [Fix 3] '''Remove log2TrafoSizeC.''' Replace "" if( log2TrafoSize > ~~Log2MinTrafoSize~~__2__ ) { if( cbf_cb[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, '''log2TrafoSizeC, trafoDepth''', scanIdxC, 1 ) if( cbf_cr[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, '''log2TrafoSizeC, trafoDepth''', scanIdxC, 2 ) } else if( blkIdx = = 3 ) { if( cbf_cb[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( xC, yC, '''log2TrafoSizeC, trafoDepth''', scanIdxC, 1 ) if( cbf_cr[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( xC, yC, '''log2TrafoSizeC, trafoDepth''', scanIdxC, 2 ) }"" with "" if( log2TrafoSize > ~~Log2MinTrafoSize~~__2__ ) { if( cbf_cb[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, '''log2TrafoWidth-1, log2TrafoHeight-1''', scanIdxC, 1 ) if( cbf_cr[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, '''log2TrafoWidth-1, log2TrafoHeight-1''', scanIdxC, 2 ) } else if( blkIdx = = 3 ) { if( cbf_cb[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( xC, yC, '''log2TrafoWidth, log2TrafoHeight''', scanIdxC, 1 ) if( cbf_cr[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( xC, yC, '''log2TrafoWidth, log2TrafoHeight''', scanIdxC, 2 ) }"". __[Issue 4]__ When log2TrafoSize is equal to Log2MinTrafoSize and firstChromaCbf is equal to 0, both chroma cbfs are not present and inferred to be equal to 0. This is not correct since in that case they should be inferred to be equal to the one from one depth above (TrafoDepth-1) Furthermore the chroma cbf parsing is a bit inconsistent since for some case it is inferred to be equal to 1 in the syntax table and for some cases it is inferred to be equal to 0 in the semantics. [Fix 4] Replace in transform_tree syntax ''' "" readCbf = TRUE '''if( blkIdx = = 3 && log2TrafoSize < Log2MaxTrafoSize )''' '''readCbf = cbf_cb[ xBase ][ yBase ][ trafoDepth ] | |''' '''cbf_cb[ xBase + ( 1 << log2TrafoWidth ) ][ yBase ][ trafoDepth ] | | ''' '''cbf_cb[ xBase ][ yBase + ( 1 << log2TrafoHeight ) ][ trafoDepth ]''' '''if( !readCbf )''' '''cbf_cb[ x0 ][ y0 ][ trafoDepth ] = 1''' '''else''' '''cbf_cb[ x0 ][ y0 ][ trafoDepth ]''' "" with "" '''if( blkIdx < 3 | | log2TrafoSize = = Log2MaxTrafoSize | | ''' '''cbf_cb[ xBase ][ yBase ][ trafoDepth ] | | ''' '''cbf_cb[ xBase + ( 1 << log2TrafoWidth ) ][ yBase ][ trafoDepth ] | |''' '''cbf_cb[ xBase ][ yBase + ( 1 << log2TrafoHeight ) ][ trafoDepth ] )''' '''cbf_cb[ x0 ][ y0 ][ trafoDepth ]''' "" Replace in transform tree semantics ""When cbf_cb[ x0 ][ y0 ][ trafoDepth ] is not present''' and PredMode is not equal to MODE_INTRA''', the value of cbf_cb[ x0 ][ y0 ][ trafoDepth ] is inferred '''to be equal to 0.'''"" with ""When cbf_cb[ x0 ][ y0 ][ trafoDepth ] is not present, the value of cbf_cb[ x0 ][ y0 ][ trafoDepth ] is inferred '''as follows. • – If all of the following conditions are true, cbf_cb[ x0 ][ y0 ][ trafoDepth ] is inferred to be equal to 1. '''– blkIdx is equal to 3''' '''– log2TrafoSize is less than Log2MaxTrafoSize''' '''– cbf_cb[ xBase ][ yBase ][ trafoDepth ] is equal to 0''' '''– cbf_cb[ xBase + ( 1 << log2TrafoWidth ) ][ yBase ][ trafoDepth ] is equal to 0''' '''– cbf_cb[ xBase ][ yBase + ( 1 << log2TrafoHeight ) ][ trafoDepth ] is equal to 0''' '''• – Otherwise if firstChromaCbf is equal to 0 and log2TrafoSize is equal to Log2MinTrafoSize, cbf_cb[ x0 ][ y0 ][ trafoDepth ] is inferred to be equal to cbf_cb[ xBase ][ yBase ][ trafoDepth − 1 ]''' '''• – Otherwise, cbf_cb[ x0 ][ y0 ][ trafoDepth ] is inferred to be equal to 0."".''' Note that the condition on intra is a leftover from when chroma cbf handling was different for inter and intra. Same fixes and cleanups apply for cbf_cr. The cleanup for the derivation when not present also applies for cbf_luma with the difference that it is only inferred to be equal to 1 when not present. __[cleanup 1]__ Move parsing of and conditioning on no_residual_data_flag to coding unit syntax since it affects trafoDepth 0 (root) only and is not changed during recursion. __[cleanup 2]__ Similarly, maxDepth can be derived once in coding unit syntax. __[cleanup 3]__ Replace intraSplitFlag by (IntraSplitFlag && trafoDepth == 0 ) to avoid confusion with IntraSplitFlag __[cleanup 4]__ interSplitFlag is only needed to derive split_transform_flag when not present. Consequently the derivation can be moved to split_transform_flag semantics and excluded in MaxDepth calculation since the related max_transform_hierarchy_depth_inter equal to 0 prevents the signaling of split_transform_flag then." bbross D6 (H1003) dI/dJ/dK 463 Text / HM mismatch for derivation of QP in deblocking processes Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-05T03:43:15+02:00 2012-04-27T19:07:11+02:00 "The CD text misses the ""0"" QP setting for I_PCM regions. Instead, qPL is set equal to 0 if q0,0 is coded by I_PCM. Attachment is a suggested text that fixes the current CD text bug and aligns it with HM software. The suggested text also solves the issues in Ticket 441. " kchono D6 (H1003) dI/dJ/dK 465 Typos in equations (8-262), (8-264), and one under the (8-264). Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-05T04:04:37+02:00 2012-04-27T19:07:40+02:00 """QP/6"" should be ""qP/6.""" kchono D6 (H1003) dI/dJ/dK 467 Typo and editorial enhancemend in Field indication SEI Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-05T04:19:07+02:00 2012-11-30T15:42:16+01:00 "[Typo] Table D-1's title is incorrect. The title should be replaced by ""Interpretation of combinations of sequence_type_flag and progressive_source_flag values"" as in JCTVC-H0720.doc [Editorial enhancement] The note of sequence_type_flag semantics should be improved. Access units containing pictures that represent 1080i fields cannot have dimensions of 1920x540 because the minimum CU size is 8 in the current spec. The following text may be more appropriate: ""NOTE - The video coding layer of HEVC does not treat access units conveying pictures that represent fields or frames differently. A sequence of pictures that represent fields would therefore be coded with picture dimensions of a field. For example, access units containing pictures that represent 1080i fields would commonly have dimensions of 1920x544 when its minimum coding unit size is equal to 8, while the sequence picture rate would express the rate of the source fields (typically between 50 Hz and 60 Hz), instead of the source frame rate (typically between 25 and 30 Hz).""" kchono D6 (H1003) dI/dJ/dK 473 outdated initValue tables in WD following JCTVC-H0535 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-08T00:05:21+02:00 2012-07-14T20:08:05+02:00 "When JCTVC-H0535 was implemented in the HM(http://hevc.kw.bbc.co.uk/trac/changeset/2052) the tables mapping ctxIdx to initValue were updated, but the equivalent tables in the WD(9-36 to 9-62) were not, resulting in wrong pStateIdx when the algorithm in 9.2.1.1 is followed. (Note that some of the changes introduced by r2052 don't produce the same ctxIdx => pStateIdx mapping as before. For example, take sao_merge_up_flag with ctxIdx 0, before r2052, initValue is 109 giving pStateIdx 49; after r2052, initValue is 175 giving pStateIdx 50. I don't know if this is intentional.)" Smarter D6 (H1003) dI/dJ/dK 476 Missing text regarding bypassing deblock filter process in lossless coding Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-09T16:01:03+02:00 2012-06-01T22:31:55+02:00 "In Section 8.7.1.4.5 and Section 8.7.1.4.6, the text regarding bypassing deblock filter process in lossless coding is missing in the current CD. However, the related text was submitted in the JCTVC-H0530 contribution document, H0530-WD-r3. In the attached document, the missing text is inserted back in Section 8.7.1.4.5 and Section 8.7.1.4.6. " wen.gao D6 (H1003) dI/dJ/dK 478 "2nd & 4th ""If"" statement in combine list initialization is vague and not precise." Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-11T11:23:33+02:00 2012-06-13T12:02:19+02:00 "The language of the 2nd and 4th ""if"" statement in step 3 of subclause 8.3.4.3 is vague and not precise, as it is really difficult to know what ""first occurance of the reference picture"" actually means. I propose editorial to change Step 3 of Subclause 8.3.4.3 as follows: Replace – If the entry RefPicListL0[ refIdxL0 ] is the first occurance of the reference picture, PredLCToPredLx[ refIdxLC ] = Pred_L0, (8 12) ..... with – If the element RefPicList0[ refIdxL0 ] is not in the reference picture list RefPicList2, RefPicList2[ refIdxL2 ] = RefPicList0[ refIdxL0 ], (8 12) PredL2ToPredLx[ refIdxL2 ] = Pred_L0, ...... And similarly, replace – If the entry RefPicListL1[ refIdxL1 ] is the first occurance of the reference picture, PredLCToPredLx[ refIdxLC ] = Pred_L1, (8 13) ..... with – If the element RefPicList1[ refIdxL1 ] is not in the reference picture list RefPicList2, RefPicList2[ refIdxL2 ] = RefPicList1[ refIdxL1 ], (8 13) PredL2ToPredLx[ refIdxL2 ] = Pred_L1, ...... Also note that there is a defect in the List name RefPicList0 and RefPicList1, they sometimes appear as RefPicListL0 and RefPicListL1. I suggest that all occurances of RefPicListL0 and RefPicListL1, be replaced with RefPicList0 and RefPicList1, to be consistent with the AVC text. While we are at it, we may as well change the following variable names....... as ""LC"" and ""lc"" are not good variables as they are used elsewhere for other tools. PredLCToPredLx to PredL2ToPredLx RefIdxLCToRefIdxLx to RefIdxL2ToRefIdxLx num_ref_idx_lc_active_minus1 to num_ref_idx_l2_active_minus1 ref_pic_list_modification_flag_lc to ref_pic_list_modification_flag_l2 refIdxLC to refIdxL2 (I already used this above) mvd_lc to mvd_l2 Pred_LC to Pred_L2 mvp_lc_flag to mvp_l2_flag luma_weight_lc_flag to luma_weight_l2_flag delta_luma_weight_lc to delta_luma_weight_l2 luma_offset_lc to luma_offset_l2 chroma_weight_lc_flag to chroma_weight_l2_flag delta_chroma_weight_lc to delta_chroma_weight_l2 delta_chroma_offset_lc to delta_chroma_offset_l2 " tktan D6 (H1003) dI/dJ/dK 482 References to StCurr0/1 should be changed StCurrBefore/After Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-11T21:52:44+02:00 2012-06-13T12:03:00+02:00 Section 8.3.3.1 contains references to RefPicSetStCurr0 (twice), RefPicSetStCurr1 (twice), NumPocStCurr0, NumPocStCurr1, PocStCurr0, and PocStCurr1. These should be changed to the RefPicSetStCurrBefore, RefPicSetStCurrAfter, NumPocStCurrBefore, NumPocStCurrAfter, PocStCurrBefore, and PocStCurrAfter, respectively. adarsh D6 (H1003) dI/dJ/dK 483 Redundant deblocking process in inner regions of I_PCM Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-12T04:07:01+02:00 2012-06-01T22:33:27+02:00 "In the draft text, inner regions of an I_PCM coding unit are subject to deblocking if its coding unit size is larger than (1<> (log2_parallel_merge_level_minus2 + 2)) ! = ((xP − 1) >> (log2_parallel_merge_level_minus2 + 2)) | | (yP >> (log2_parallel_merge_level_minus2 + 2)) ! = ((yP + nPSH − 1) >> (log2_parallel_merge_level_minus2 + 2) Otherwise, refIdxLX is set equal to 0. }}} When the singleMCLFlag is equal to 1, however, this may leads to the second PU of a 8x8 CU use a different reference index than the first PU of the same CU, which is incorrect. The suggested fix is to modify the second condition of the first ""If"" statement as: {{{ – the PartIdx is equal to 0 or the singleMCLFlag is equal to 1 }}} Note that the HM6.1 software already operates as suggested. Thus we don’t need to modify the software. For more detail, please check the getInterMergeCandidates() function, which is called with uiPUIdx==0 whenever the singleMCLFlag condition is true." huiyong D6 (H1003) dI/dJ/dK 486 Clarification needed for obtaining tc / beta values when deblocking accross slice Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-13T03:00:49+02:00 2012-06-01T22:33:53+02:00 "Like AVC, HEVC can deblock accross slices, and the two slices can have different values for beta_offset_div2 and tc_offset_div2. The text should explain how to obtain the correct value of these parameters. This is the text from AVC 8.7.2, which should be pretty close to what the HEVC text can use: Let filterOffsetA and filterOffsetB be the values of FilterOffsetA and FilterOffsetB as specified in subclause 7.4.3 for the slice that contains the macroblock containing sample q0." pieterkapsenberg D6 (H1003) dI/dJ/dK 488 Unclarity and verboseness in long-term reference pictures marking process Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-14T16:59:00+02:00 2012-11-30T15:42:16+01:00 "Section 8.3.2 contains the sentences: Short-term reference pictures are identified by their PicOrderCntVal values. Long-term reference pictures are identified by their pic_order_cnt_lsb values. The second sentence is wrong because PicOrderCntVal is also used for long-term pictures when delta_poc_msb_present_flag is equal to one in the following pseudo-code. In the following section the terms ""used for short-term reference"", ""used for short-term reference"" and ""used for reference"" are introduced an the shortcuts ""short-term reference picture"" and ""long-term reference picture"" which seem redundant. The pseudo code under ""1"" repeats the same actions for a ""short-term reference picture"" or a ""long-term reference picture"". This can be simplified using ""used for reference"" definition." ksuehring D6 (H1003) dI/dJ/dK 491 Subclauses 7.4.3.2 and 7.4.3.3, cross reference Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-16T05:13:09+02:00 2012-06-13T12:03:18+02:00 "The cross reference in semantics of ref_pic_list_modification_flag_lc defined in 7.4.3.3 is wrong. Replace 8.3.4.2 with 8.3.4.3. And, for the clarification, it may be better to refer to subclause 8.3.4.2 for the semantics of ref_pic_list_modification_flag_lX defined in 7.4.3.2. e.g. Add “as specified in 8.3.4.2” to the end of sentence of “ref_pic_list_modification_flag_lX equal to 0 indicates that reference picture list X is determined implicitly”. " suzukiyos D6 (H1003) dI/dJ/dK 493 Derivation process error for luma intra prediction mode Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-19T08:50:42+02:00 2012-07-14T20:08:04+02:00 "candModeList[0] = candIntraPredModeA (8 24) candModeList[1] = 2 + ( ( candIntraPredModeA − 2 − 1 ) % 32 (8 25) candModeList[2] = 2 + ( ( candIntraPredModeA − 2 + 1 ) % 32 (8 26) In Intra_Angular (33) mode, candModeList[0] is 33, candModeList[1] = 32, and candModeList[2] = 2 (instead of 34). In Intra_Angular (34) mode, candModeList[0] is 34, candModeList[1] = 33, and candModeList[2] = 3 (instead of 0 or 1 : non-angular modes). Mod 32 operator is correct for those cases? " sunnykr D6 (H1003) dI/dJ/dK 494 "8.4.3.1.6 Specification of Intra_Angular (2..9, 11..25, 27..34) prediction mode" Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-19T16:51:29+02:00 2012-04-28T18:51:45+02:00 "In 8.4.3.1.6, when intraPredMode is 18, Table 8-5 sets intraPredAngle to -32. Then, after equation (8-47) is applied, (8-48) is applied because intraPredAngle is less than 0. However, (8-48) uses invAngle, and Table 8-6 does not specify invAngle for intraPredMode=18. Similarly, suppose intraPredMode is between 11 and 17, inclusive. This is less than 18, so (8-50) is applied. Because modes 11-17 have intraPredAngle values less than zero, (8-51) is applied. However, (8-51) uses invAngle, and Table 8-6 does not contain assign invAngle values to modes 11-17. Modifying the top row of Table 8-6 may be a solution, by changing the values From: 2, 3, 4, 5, 6, 7, 8, 9 To: 18, 17, 16, 15, 14, 13, 12, 11 We may also want to see if this affects ticket #339. " cohen D6 (H1003) dI/dJ/dK 500 Redundant cbf_cb and cbf_cr flags when log2MaxTrafoSize is set to two Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-24T02:37:34+02:00 2012-06-29T18:53:52+02:00 "Similar to the previous HM ticket #312, the working draft also has the issue that when log2MaxTrafoSize is two, there are three redundant cbf_cb and cbf_cr flags for each 4x4 chroma TU. In section 7.3.8 transform tree syntax, firstChromaCbf is derived as follows: {{{ firstChromaCbf = ( log2TrafoSize = = Log2MaxTrafoSize | | trafoDepth = = 0 ) ? 1 : 0 }}} The above formula does not consider the case when log2MaxTrafoSize is two. In that case, bFirstCbfOfCU is always true for each 4x4 luma TU, which in turn causes a set of cbf_cb and cbf_cr flags to be coded. Although only the 4th luma TU is associated with a chroma TU and should contain a set of coded cbf_cb and cbf_cr flags. A possible fix may be to replace the above formula by the following one {{{ firstChromaCbf = ((log2TrafoSize == log2MaxTrafoSize && (log2TrafoSize > 2 || blkIdx == 3)) || trafoDepth == 0 ) }}}" zhyang123 D6 (H1003) dI/dJ/dK 509 Subclause reference error in 8.1 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-28T20:27:29+02:00 2012-06-13T12:04:02+02:00 "The string ""as specified in subclause 8.3.5."" in subclause 8.1 should be replaced by ""as specified in subclause 8.3.6.""" rickard D6 (H1003) dI/dJ/dK 510 nal_ref_idc should be replaced by nal_ref_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-28T20:30:12+02:00 2012-06-13T12:04:26+02:00 'nal_ref_idc' should be replaced by 'nal_ref_flag' in subclause 8.3.6 rickard D6 (H1003) dI/dJ/dK 512 issue on lists_modification_present_flag and ref_pic_list_combination() Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-30T16:43:43+02:00 2012-06-13T12:04:50+02:00 "JCTVC-H0412, which proposed lists_modification_present_flag, was adopted at the SanJose meeting, but it was not incorporated correctly. It caused the following problem: ref_pic_list_combination_flag and num_ref_idx_lc_active_minus1 which are parsed in ref_pic_list_combination() are undefined when lists_modification_present_flag is equal to 0. The fix is included in JCTVC-H0412r1. " suzukiyos D6 (H1003) dI/dJ/dK 517 Clip function for SAO text Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-03T09:47:17+02:00 2012-06-11T22:33:20+02:00 "In 8.7.2.1.1 (H1003_dK)text, Clip3() should be added to SAO output in equation (8-353) and equation (8-355). The modifications are as follows: 1.(8-353) recSaoPicture[ xC + i, yC + j ] = Clip3(0,( 1 << bitDepth ) − 1 , recPicture[ xC + i, yC + j ] + saoValueArray[ edgeTable[ edgeIdx ] ]) 2.(8-355) recSaoPicture[ xC + i, yC + j ] = Clip3(0,( 1 << bitDepth ) − 1 ,recPicture[ xC + i, yC + j ] + saoValueArray[ bandTable[ bandIdx ] ] ) " chiayang_tsai D6 (H1003) dI/dJ/dK 518 Fix for fixed-length (FL) binarization process Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-03T11:01:16+02:00 2012-06-11T22:33:57+02:00 "In 9.2.2.5 (H1003_dk), the fixed-length binarization order should be from MSB to LSB. The text should be modified as follows: .......The indexing of bins for the FL binarization is such that the binIdx = 0 relates to the ""most"" significant bit with increasing values of binIdx towards the ""least"" significant bit. " chiayang_tsai D6 (H1003) dI/dJ/dK 525 The size of chroma component in pcm_samle() is different from HM software. Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-04T22:32:59+02:00 2012-07-11T16:02:16+02:00 "The size of chroma component in text is same as 422, not 420. Change the PCM syntax 7.3.7.2 as follows. pcm_sample( x0, y0, log2CbSize ) { for( i = 0; i < 1 << ( log2CbSize << 1 ); i++ ) pcm_sample_luma[ i ] for( i = 0; i < ( 1 << ( log2CbSize << 1 ) ) >> 2; i++ ) pcm_sample_chroma[ i ] NumPCMBlock-- } " kchono D6 (H1003) dI/dJ/dK 526 Cr sample location in pcm_sample_chroma in eq. 8-18 is wrong Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-04T22:35:24+02:00 2012-07-14T20:08:02+02:00 "The offset for Cb is not considered. Correct the eq. 8-18 as follows: recSamplesCr[ xB/2 + i, yB/2 + j ] = pcm_sample_chroma[ ( nS/2 * ( j + nS/2 ) ) + i ] << ( BitDepthC – PCMBitDepthC ) with i, j = 0..nS/2-1 " kchono D6 (H1003) dI/dJ/dK 527 Typo in derivation of MinCbAddrZS Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-05T17:33:15+02:00 2012-06-12T18:26:17+02:00 "The inner loop of ""Derivation process for the minimum coding block address of a coding block"" is: {{{ for (i = 0, p = 0; i < Log2CtbSize - Log2MinCbSize; i++) { m = 1 << i p += (m & x ? m*m : 0) + (m & y ? 2*m*m : 0) MinCbAddrZS[x][y] += p } }}} But to get a proper zscan order(e.g. (0, 0) => 0, (0, 1) => 2, (1, 0) => 1, (1, 1) => 3), either the ""p +="" should be a ""p ="" or the ""MinCbAddrZS[x][y] += p"" should be after the loop. (Additionally, since Log2CtbSize - Log2MinCbSize == log2_diff_max_min_coding_block_size, I don't see why the later isn't used)." Smarter D6 (H1003) dI/dJ/dK 528 Text about ALF output clipping Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-06T10:02:10+02:00 2012-06-29T18:30:52+02:00 "In JCTVC-H1003_dK, the reconstructed sample of ALF output should be clipped as in HM. The text modifications are as follow: In 8.7.3.4, recFiltPictureL[ xC + x][ yC + y ] = Clip1Y(( recFiltPictureL[xC + x][yC + y] + ( 1 << ( alfPrecisionBit − 1) ) ) >> alfPrecisionBit) In 8.7.3.5, recFiltPictureC[ xC + x][ yC + y ] = Clip1C(( recFiltPictureC[xC + x][yC + y] + ( 1 << ( alfPrecisionBit − 1) ) ) >> alfPrecisionBit) " chiayang_tsai D6 (H1003) dI/dJ/dK 529 Mismatch between WD6 and HM6.2 - deblocking filter Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-06T19:56:41+02:00 2012-06-01T22:34:29+02:00 HM6.1/6.2 consider bit-depth (variable ''iBitdepthScale'') for computing '''Tc''' and '''Beta''' in deblocking filter process for both luma and chroma (''TComLoopFilter::xEdgeFilterLuma'' and ''TComLoopFilter::xEdgeFilterChroma'') but this is not reflected in WD6 (JCTVC-H1003_dK) respectively in sections ''8.7.1.4.5 Filtering process for a luma sample'' & ''8.7.1.4.6 Filtering process for a chroma sample''. pandrivon D6 (H1003) dI/dJ/dK 533 Incorrect derivation of ColumnWidth and RowHeight with uniform_spacing_flag Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-09T13:09:24+02:00 2012-05-16T14:12:43+02:00 "This following report is based on I0030. When uniform_spacing_flag is used, the pseudocode for deriving ColumnWidth and RowHeight does not work properly (see equations 7-20 and 7-21). As an example, for a picture width of 23 CTBs and with three tiles, three tiles of 8 CTBs in width will be allocated. The following pseudocode is suggested as a replacement for ColumnWidth and RowHeight derivations respectively: if( uniform_spacing_flag ) { MinTileWidth = Floor( PicWidthInCtbs / (num_tile_columns_minus1 + 1) ) TotalColumnWidths = 0 for( i = 0; i <= num_tile_columns_minus1; i++ ) { ColumnWidth[ i ] = MinTileWidth TotalColumnWidths += MinTileWidth ColumnWidthInLumaSamples[ i ] = ColumnWidth[ i ] << Log2CtbSize } i = 0 while( TotalColumnWidths++ < PicWidthInCtbs ) { ColumnWidthInLumaSamples[ i ] += 1 << Log2CtbSize ColumnWidth[ i++ ] ++ if( i > num_tile_columns_minus1 ) i = 0 } } else { for( i = 0; i <= num_tile_columns_minus1; i++ ) { ColumnWidth[ i ] = column_width[ i ] ColumnWidthInLumaSamples[ i ] = ColumnWidth[ i ] << Log2CtbSize } } if( uniform_spacing_flag ) { MinTileHeight = Floor( PicHeightInCtbs / (num_tile_rows_minus1 + 1) ) TotalRowHeights = 0 for( i = 0; i <= num_tile_rows_minus1; i++ ) { RowHeight[ i ] = MinTileHeight TotalRowHeights += MinTileHeight } i = 0 while( TotalRowHeights++ < PicHeightInCtbs ) { RowHeight[ i++ ] ++ if( i > num_tile_rows_minus1 ) i = 0 } } else { for( i = 0; i <= num_tile_rows_minus1; i++ ) { RowHeight[ i ] = row_height[ i ] } } " stworrall D6 (H1003) dI/dJ/dK 536 Descriptor of alf_run_diff Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-05-15T12:10:06+02:00 2012-06-29T18:32:00+02:00 "In 7.3.3.5 When condition (""lcuIdx - numCtbInWidth <0) is false, the descriptor of '''""alf_run_diff""''' is '''se(v)''', not '''s(v)'''." whchung D6 (H1003) dI/dJ/dK 370 purpose of tile_control_present_flag Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-03-01T17:19:00+01:00 2012-06-13T12:00:10+02:00 "The syntax element of tile_control_present_flag is only used to determine whether loop_filter_across_tiles_enabled_flag is present. In previous WD, the tile_control_present_flag syntax element indicated that the loop_filter_across_tiles_enabled_flag and/or the tile_boundary_independence_flag may be present. With the removal of dependent tiles, there was no longer a need for the tile_boundary_independence_flag syntax element and it was removed leaving the loop_filter_across_tiles_enabled_flag as the only syntax element indicated by the tile_control_present_flag." bbross D6 (H1003) dI/dJ/dK 406 terminology sample vs. pixel Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-03-15T09:53:07+01:00 2012-06-11T22:33:00+02:00 "From dI editing notes: [Ed. (GJS): Is a pixel something like a sample, or is it something else?] [Ed. (GJS): Study/apply consistency with respect to ""pixel"" versus ""sample"". Are they different things?] Currently pixel is used in - in-loop filters semantics for pcm_loop_filter_disable_flag and sao_band_position - in-loop filters processes - 8.4.3 Decoding process for intra blocks - Annex A in Table A-1/A-4/A-5 ""Max luma pixel rate MaxLumaPR (samples/sec)"", pixel rate in samples/sec? In my opinion, all occurrences of pixel* could be replaced by sample*. " bbross D6 (H1003) dI/dJ/dK 437 Split flag conditions Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-03-25T06:25:51+02:00 2012-11-30T15:42:16+01:00 "For WD H1003 Rev K (21): In section 7.4.5 Coding tree semantics, for split_coding_unit_flag, mention the boundary CUs (LCUs) which traverse the picture boundary on the right or bottom are processed as if a split flag were present, inferred. " rkaliski D6 (H1003) dI/dJ/dK 451 use_delta_flag[ j ] is not decoded when used_by_curr_pic_flag[ j ] is 1. Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-03-30T09:07:27+02:00 2012-05-15T16:07:04+02:00 "Change the value use_delta_flag[ j ] in the first row of Table 7-9 from ""1"" to ""inferred"". " tktan D6 (H1003) dI/dJ/dK 461 Position of Subclause 8.3.5 Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-04-04T11:21:43+02:00 2012-06-13T12:22:59+02:00 "The subclause 8.3.5 Marking of reference pictures before decoding is invoked once per picture, after decoding of a slice header and the decoding process for reference picture set as specified in 8.3.2 but prior to the decoding of any coding unit and prior to the decoding process for reference picture list construction of the slice as specified in subclause 8.3.3. We should move it to between subclauses 8.3.2 and 8.3.3 and renumber the subclauses. " tktan D6 (H1003) dI/dJ/dK 464 Definition of quantization parameter Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-04-05T04:00:28+02:00 2012-11-30T15:42:16+01:00 "In 8.6.1, the meanings of QPY_A, QPY_B, and QPY_PREV may be ambiguous a little bit because luma quantization parameters are QP'Y_A, QP'Y_B, and QP'Y_PREV. Since QPY and QP'Y are different parameters, it may be better to use other word instead of ""luma quantization parameter"" for referring to QPY_A, QPY_B, and QPY_PREV. " kchono D6 (H1003) dI/dJ/dK 471 Improved text for pcm_flag and num_subsequent_pcm semantics Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-04-06T06:09:12+02:00 2012-08-03T12:17:43+02:00 "1. In the pcm_flag semantics, the inference of pcm_flag value is incorrect when the pcm_flag is not present due to the presence of num_subsequent_pcm in a previously coded coding unit, although the corrected inference is described in the num_subsequent_pcm semantics. 2. In the num_subsequent_pcm semantics, the meaning of ""subsequent coding units"" and ""subsequent I_PCM coding units"" are a little bit ambiguous. Attachment includes suggested texts to improve the specifications of pcm_flag and num_subsequent_pcm semantics. " kchono D6 (H1003) dI/dJ/dK 479 We do not have SP pictures / text copied from AVC is not updated. Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-04-11T11:46:42+02:00 2012-06-13T12:02:44+02:00 "Subclause 8.1, second last paragraph of step 2.: Editorial: a) remove "", SP,"" b) ""subclause 8.3.3"" should be subclause ""8.3.4"" c) add to the end of the sentence ""and reference picture list combination (RefPicList2)"". i.e. Change – At the beginning of the decoding process for each P, SP, or B slice, the decoding process for reference picture lists construction specified in subclause 8.3.3 is invoked for derivation of reference picture list 0 (RefPicList0), and when decoding a B slice, reference picture list 1 (RefPicList1). to At the beginning of the decoding process for each P or B slice, the decoding process for reference picture lists construction specified in subclause 8.3.4 is invoked for derivation of reference picture list 0 (RefPicList0), and when decoding a B slice, reference picture list 1 (RefPicList1) and reference picture list combination (RefPicList2). Subclause 8.3.4.1, third paragraph: Editorial: a) remove ""or SP"" b) add to the end of the paragraph "", used for bi-prediction and a third RefPicList2 used for uni-prediction"". i.e. Change Reference pictures are addressed through reference indices as specified in subclause 8.3.2. A reference index is an index into a reference picture list. When decoding a P or SP slice, there is a single reference picture list RefPicList0. When decoding a B slice, there is a second independent reference picture list RefPicList1 in addition to RefPicList0. to Reference pictures are addressed through reference indices as specified in subclause 8.3.2. A reference index is an index into a reference picture list. When decoding a P slice, there is a single reference picture list RefPicList0. When decoding a B slice, there is a second independent reference picture list RefPicList1 in addition to RefPicList0, used for bi-prediction and a third RefPicList2 used for uni-prediction. Subclause 8.3.4.1, fifth paragraph: Editorial: Change When the slice is a B slice, the mapping process for reference picture lists combination in B slices is applied as specified in subclause 8.3.4.3. to When the slice is a B slice, RefPicList2 is derived and the mapping process to RefPicList0 and RefPicList1 is applied as specified in subclause 8.3.4.3. " tktan D6 (H1003) dI/dJ/dK 470 Shortcoming of lossless functionality Text D6 (H1003) dI/dJ/dK technical change bbross closed 2012-04-05T16:35:11+02:00 2012-06-12T17:02:52+02:00 "This is not really a bug but it is rather a possible shortcoming of lossless coding at CU level. If a CU needs to be encoded losslessly, but the residue is zero, cu_qp_delta cannot be transmitted. One may force the encoder to use another prediction mode in order to get a non-zero residue (just for the sake of transmitting cu_qp_delta) but there may be no prediction mode with any residue. In that case the block cannot be treated as lossless (for instance because DBF will be active). Conversely, if a block needs to be encoded in a lossy way, but the predicted QP is zero and there is no residue, it is not possible to indicate that lossy coding is active and that we want the block to be filtered. One solution can be to enforce lossless coding at slice level only, or, if one wants CU lossless granularity, to have a slice level flag that allows lossless coding in the current slice, and then, if this flag is active, an extra CU level flag for lossless coding." felix.henry D6 (H1003) dI/dJ/dK 375 Typos for num_substreams_minus1 Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-02T10:54:47+01:00 2012-06-13T12:06:17+02:00 In version dk, num_substreams_minus1 is referred to as num_substream_minus1 (missing 's') in the slice data syntax table (section 7.3.4). stworrall D6 (H1003) dI/dJ/dK 386 typo in log2_diff_max_min_coding_block_size semantics Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-06T16:06:06+01:00 2012-06-13T12:06:30+02:00 Equation 7-13: remove non-breaking space between log2_min_coding_block_size_minus and 3. bbross D6 (H1003) dI/dJ/dK 442 "Spurious extra variable ""shift3""" Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-03-28T18:35:01+02:00 2012-03-29T10:10:44+02:00 "The variable ""shift3"" is defined in clause 8.5.2.2.2.1 and 8.5.2.2.2.2 but I don't see that it ever gets referenced. Real version is H1003-v21" rikallen D6 (H1003) dI/dJ/dK 462 Incorrect cross reference in section 9.2.2 Binarization process Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-04T16:27:57+02:00 2012-07-04T19:57:56+02:00 "4th paragraph, ""binarization process are given in subclauses 9.2.2.5 to 9.2.2.5"" Should read ""binarization process are given in subclauses 9.2.2.1 to 9.2.2.5"" " rikallen D6 (H1003) dI/dJ/dK 481 RefPicListX is not a function, is it? Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-11T12:21:24+02:00 2012-06-12T18:34:02+02:00 "Is RefPicListX ever defined as a function? I think not and it is actually an array. But I find many occurances of PicOrderCnt( RefPicListX( refIdxLX ) ). Shouldn't this be PicOrderCnt( RefPicListX[ refIdxLX ] )? " tktan D6 (H1003) dI/dJ/dK 508 Typo in slice_granurality Text D6 (H1003) dI/dJ/dK defect bbross closed 2012-04-28T20:07:20+02:00 2012-06-13T12:06:42+02:00 There is an instance of slice_granurality that should be changed to slice_granularity jsampedro D6 (H1003) dI/dJ/dK 371 variable SignalledAsChromaDC not used anymore Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-03-01T17:22:46+01:00 2012-07-04T19:57:56+02:00 """F765 fixed number of MPM"" removed the condition on SignalledAsChromaDC in WD4 d4 (JCTVC-F803_d4.doc) and consequently it's derivation in Prediction unit syntax should be removed." bbross D6 (H1003) dI/dJ/dK 480 Editorial Spelling and spaces Text D6 (H1003) dI/dJ/dK enhancement bbross closed 2012-04-11T11:59:07+02:00 2012-06-29T18:35:42+02:00 "Subclause 7.4.2.1, definition of lists_modification_present_flag a) Space missing between ""and"" and ""ref_pic_list_combination( )"" Subclause 8.4.1, Step 3. a) The word ""minmum"" appears twice. They should be ""minimum"" " tktan D7 (I1003) d0 537 Consistency of the intra prediction mode definitions Text D7 (I1003) d0 enhancement bbross closed 2012-05-16T14:14:24+02:00 2012-07-14T20:08:05+02:00 "Intra_Angular (26) and Intra_Angular (10) prediction modes are defined in separate sections (8.4.3.1.3 and .4) although their definitions are consistent with the rest of the intra angular modes (defined in section 8.4.3.1.6). I would propose to make the text more consistent by deleting sections 8.4.3.1.3 and 8.4.3.1.4, changing ""-"" to ""0"" in table 8-5 for intraPredAngles 10 and 26, and adding the intra prediction smoothing process applicable to modes 10 and 26 to the end of section 8.4.3.1.6. " jani.lainema D7 (I1003) d1 589 Seeing a discrepancy in SAO bandTable updation in JCTVC-I1003_d4.doc Text D7 (I1003) d1 defect Chaitanya closed 2012-06-26T06:11:40+02:00 2012-06-27T12:44:29+02:00 "If we see the calculation of bandTable it is updated as for( k = 0; k < 4; k++ ) bandTable[ (k + saoLeftClass) & 31 ] = k + 1 so the array bandTable will contains values either 0 or 1 or 2 or 3 or 4. we are calculating the variable bandidx like below. The variable bandIdx is set equal to bandTable[ recPicture[ xC + i, yC + j ] >> bandShift ]. so bandidx can take any value among 0 or 1 or 2 or 3 or 4. but the offset value what we have to add to the deblocked picture output will get from SaoOffsetVal[ cIdx ][ rx ][ ry ][ bandIdx ] . here bandidx will take value among 0 or 1 or 2 or 3 but not 4. So please have a look in to the updation of bandtable. Thanks. Regards, Chaitanya Reddy" chinna.bommu D7 (I1003) d1 372 Derivation of coefficient group scan is incorrect Text D7 (I1003) d1 defect bbross closed 2012-03-01T18:18:34+01:00 2012-06-01T22:29:45+02:00 "In the residual coding syntax, the derivation of xCG and yCG for 32x32 TUs depend on the scan array for 8x8 TUs. Since the scan order for 8x8 TUs was changed from diagonal to sub-block, xCG and yCG are now incorrect. The simplest fix would be to derive xCG as follows: xCG = ScanOrder[ log2TrafoWidth ][ log2TrafoHeight ][ scanIdx ][ 16 * i ][ 0 ] >> 2 " nnguyen D7 (I1003) d1 407 scaling_list_present_flag Text D7 (I1003) d1 defect bbross closed 2012-03-15T10:53:14+01:00 2012-06-01T22:30:07+02:00 "(actual version is H1003_dK) The semantics of scaling_list_present_flag is wrong and inconsistent with HM6 software. In CD, scaling_list_present_flag is defined as on/off switch of scaling list. However, the switch to turn on/off of scaling list is defined as scaling_list_enable_flag. The scaling_list_present_flag is to indicate if default matrix is used or scaling list data is present in bitstream. The semantics should be replaced as follows. ""scaling_list_present_flag equalto 0 specifies that the value of scaling list is not present and the value of all scaling lists are set equal to the default scaling list “ In addition, scaling list on/off switch in de-quantization process in 8.6.3 should use scaling_list_enable_flag rather than scaling_list_present_flag. " teruhiko D7 (I1003) d1 538 typo in 8.3.4.2 Text D7 (I1003) d1 defect bbross closed 2012-05-17T23:21:52+02:00 2012-05-18T12:23:46+02:00 "In 8.3.4.2, When the slice is a B slice, the list RefPicList1 is constructed as follows: for( cIdx = 0; cIdX ≤ num_ref_idx_l1_active_minus1; cIdx++) '''RefPicList0'''[ cIdx ] = ref_pic_list_modification_flag_l1 ? RefPicListTemp1[ list_entry_l1[ cIdx ] ] : RefPicListTemp1[ cIdx ] RefPicList0 shall be RefPicList1." eeehey D7 (I1003) d1 540 "Phrase ""one of the following conditions is true""" Text D7 (I1003) d1 defect bbross closed 2012-05-23T10:25:06+02:00 2012-06-01T22:34:54+02:00 "[Ed. (GJS): Inspect the text as a whole to remove all places where it says ""one of the following conditions"" when it means ""any of the following conditions"", as this seems to cause problems in the case where more than one of the conditions is true.]" bbross D7 (I1003) d1 544 Non-normative aspects in scaling process (8.6.3) should be removed Text D7 (I1003) d1 defect bbross closed 2012-05-24T20:27:30+02:00 2012-06-01T22:35:11+02:00 "Equations (8-262), (8-264), and (8-270) should be removed as they relate to a specific implementation to avoid 32-bit overflow in some corner cases. Removing these equations has no normative impact. levelLimit defined in equations (8-262) and (8-264) takes value 15 most of the time, and value 14 for a combination of log2TrSize=2 and large qP values such that BitDepth - qP/6 = 0. The case where levelLimit is 15 is not relevant anymore following adoption of I0254. In the case where levelLimit is 14, the clipping to the -16384..16383 range defined in (8-270) has no effect on the value computed in (8-271) since (8-271) scales the output of (8-270) by a factor of at least 40 and defines another clipping operation to the -32768..32767 range. The clipping operation of (8-270) should thus be removed from the specification as it has no normative effect. For simplicity, it may also be preferable to define the scaling process using a single equation (without changing the normative behavior): d_ij = Clip3( −32768, 32767,( ( c_ij * M[i][j] * levelScale[ qP%6 ] << ( qP/6 ) ) + ( 1 << ( shift + 3 ) ) ) >> (shift + 4) ) where M[i][j] = 16 if scaling_list_present_flag is equal to 0 It may be appropriate to add a note to clarify than for c_ij = -32768, M[i][j] = 255, qP = 51, and shift = 1, the correct value of d_ij is -32768 (and not 32767, which is the value one might get if not correctly implementing corner cases). " fbossen D7 (I1003) d1 588 Typo in pseudo codes in 9.2.2.6 Binarization process for cu_qp_delta Text D7 (I1003) d1 defect bbross closed 2012-06-26T02:33:32+02:00 2012-06-29T18:34:27+02:00 "According to JCTVC-F754, ""cNum--"" should be ""--cNum."" However, the current spec does not define the prefix decrement operator. A reasonable fix would be to decrement the cNum in advance. The fix is described in the attachment." kchono D7 (I1003) d1 542 cb_qp_offset and cr_qp_offset ranges missing in text Text D7 (I1003) d1 enhancement bbross closed 2012-05-24T12:32:27+02:00 2012-06-12T14:54:16+02:00 "According to JCTVC-I1003_d1 p.69: ""cb_qp_offset, cr_qp_offset are specifying the offset to the luma quantization parameter QP’Y used for deriving QP’Cb and QP’Cr , respectively."" However, no range is defined for those syntax elements. It seems according to I0283 that implicit range is the same as for AVC [-12..+12]. It should be formalized in the text. Then, I propose to add: ""The value of cb_qp_offset shall be in the range of −12 to +12, inclusive."" and ""The value of cr_qp_offset shall be in the range of −12 to +12, inclusive."" to be added respectively after the definition of each syntax element. " pandrivon D7 (I1003) d2 557 Annex C: reference to sub-clauses Text D7 (I1003) d2 defect bbross closed 2012-06-05T21:27:18+02:00 2012-06-11T22:34:53+02:00 "In Annex C, most of the references to sub-clauses within Annex C (such as C.1, C.2.2, etc.) are off by one section/sub-clause. Most of the wrong references are not ""linked"" to the appropriate section. " adarsh D7 (I1003) d2 558 Erorr in TileId[] derivation loop Text D7 (I1003) d2 defect bbross closed 2012-06-05T21:34:49+02:00 2012-06-11T22:35:42+02:00 "The derivation of array TileId[] is wrong in Sec. 6.5. I think the first two loops, that are ... for( j = 0, tileId = 0; j <= num_tile_columns_minus1; j++ ) for( i = 0; i <= num_tile_rows_minus1; i++, tileId++ ) ... should be ... for( j = 0, tileId = 0; j <= num_tile_rows_minus1; j++ ) for( i = 0; i <= num_tile_columns_minus1; i++, tileId++ ) ... If the existing loops are correct as they are, then the next two lines need to be corrected. Instead of ... for( y = RowBd[ j ]; y < RowBd[ j + 1 ]; y++ ) for( x = ColBd[ i ]; x < ColBd[ i + 1 ]; x++ ) ... they should be ... for( y = RowBd[ i ]; y < RowBd[ i + 1 ]; y++ ) for( x = ColBd[ j ]; x < ColBd[ j + 1 ]; x++ ) ... Because the length of RowBd[] and ColBd[] are num_tile_rows_minus1+2 and num_tile_columns_minus1+2, respectively." adarsh D7 (I1003) d2 559 log2_min_coding_block_size_minus3 and log2_diff_max_min_coding_block_size range and semantic Text D7 (I1003) d2 defect bbross closed 2012-06-06T11:05:12+02:00 2012-11-13T13:53:47+01:00 "Correct me if I am wrong, but I could not find any previous ticket or reflector discussion about range of LCU(CTB) and SCU. The current D7 (d2) do not constraint log2_min_coding_block_size_minus3 neither log2_diff_max_min_coding_block_size. I could not find such constraints in Profile section too (Annex A - A.3.2). However, I guess that Main Profile is currently defined for Max CTB = 64x64? Another minor note about semantics typo: ""Log2CtbSize = log2_min_coding_block_size_minus 3 +3..."" should be ""Log2CtbSize = log2_min_coding_block_size_minus3 +3..."" (remove space) Same remark for: ""The variable Log2MaxTrafoSize is set equal to log2_min_transform_block_size_minus 2 + 2"" should be ""The variable Log2MaxTrafoSize is set equal to log2_min_transform_block_size_minus2 + 2"" (remove space)" pandrivon D7 (I1003) d2 560 Intra transform skipping semantic issue with high bit-depth Text D7 (I1003) d2 defect bbross closed 2012-06-06T11:18:56+02:00 2012-07-02T12:47:28+02:00 "As of Draft 7 (d2), "" -If transSkipFlag is equal to 1, the following applies. 1.The variable shift is derived as follows: –If cIdx is equal to 0, shift = 13 – BitDepthY (8 269) –Otherwise, shift = 13 – BitDepthC "" However, current Draft 7 states that BitDepthY/C could be set up to 14 begetting potential negative shift definition. " pandrivon D7 (I1003) d2 561 Typo in slice_sao_interleaving_flag semantic Text D7 (I1003) d2 defect bbross closed 2012-06-06T12:35:11+02:00 2012-06-06T14:25:56+02:00 "slice_sao_interleaving_flag equal to 1 specifies that the SAO parameters are interleaved in slice data; equal to 0 specifies that the SAO parameters are in referred APS. It is a requirement of the bitstream that if there is an active APS, the value of '''slice_sao_interleaving _offset_flag''' shall be equal to aps_sao_interleaving_flag. suggestion: slice_sao_interleaving _offset_flag => slice_sao_interleaving_flag" pandrivon D7 (I1003) d2 581 Derivation pocess for luma intra prediction mode : undefined variable : candIntraPreModeN Text D7 (I1003) d2 defect bbross closed 2012-06-21T08:42:54+02:00 2012-07-14T20:08:03+02:00 "candIntraPredModeA and candIntraPredModeB are used for the first time in this chapter (Derivation pocess for luma intra prediction mode). They are never defined. I assume they should be replaced by intraPredModeA and intraPredModeB respectively. (Note that these latter are defined but never used)" chung D7 (I1003) d3 466 ALF SliceQPy range error in Table 8-14 Text D7 (I1003) d3 defect bbross closed 2012-04-05T04:07:25+02:00 2012-06-29T18:30:21+02:00 "SliceQPy can take a nagative value. ""0 - 27"" in the table should be ""-QpBdOffsetY - 27""." kchono D7 (I1003) d3 477 Semantics of vui_parameters_present_flag missing Text D7 (I1003) d3 defect bbross closed 2012-04-11T00:13:07+02:00 2012-07-14T20:08:02+02:00 The semantics of vui_parameters_present_flag is missing. adarsh D7 (I1003) d3 567 sao_type_idx is never decoded Text D7 (I1003) d3 defect bbross closed 2012-06-11T22:56:13+02:00 2012-06-13T12:05:31+02:00 In JCTVC-I1003_d3, the sao_offset_cabac() function was removed, and most of its content was moved to sao_param(), but the decoding of sao_type_idx seems to be missing. Smarter D7 (I1003) d3 568 Undefined variable nalUnitHeaderBytes used in NAL unit syntax Text D7 (I1003) d3 defect bbross closed 2012-06-12T09:43:55+02:00 2012-06-13T12:05:49+02:00 "In the NAL unit syntax table 7.3.1 the variable nalUnitHeaderBytes is used in the for-loop initializer but is not defined anywhere in the text. It could probably be replaced by a literal ""2"". The initialization of NumBytesInRBSP=0 could be moved down by two lines for aesthetical reasons." skamp D7 (I1003) d3 469 chroma_format_idc has no need for a default value Text D7 (I1003) d3 enhancement bbross closed 2012-04-05T16:26:48+02:00 2012-09-21T12:35:27+02:00 "Section 7.4.2 says ""When chroma_format_idc is not present, it is inferred to be equal to 1 (4:2:0 chroma format)."" But chroma_format_idc is always present in the SPS." parmitag D7 (I1003) d3 569 Minor textual enhancement / typo Text D7 (I1003) d3 enhancement bbross closed 2012-06-12T10:25:37+02:00 2012-06-13T12:07:11+02:00 "In the last sentence of the semantics of emulation_prevention_three_byte (7.4.1) the last underscore in ""entry_point_marker_two_3bytes_syntax"" should be replaced by a space. In the semantics of entropy_slice_flag (7.4.3) the word ""proceeding"" should probably be replaced by ""preceding"" (two occurences)." skamp D7 (I1003) d4 594 14-bit issues in Weighted Prediction Text D7 (I1003) d4 defect bbross closed 2012-06-27T18:42:50+02:00 2012-07-04T19:57:54+02:00 "In 8.5.2.2.3 Weighted sample prediction process, variable offset1 is set equal to 1<<(shift1-1) but shift1 is set equal to 14 - bitDepth. If bitDepth equals to 14 then we have a negative shift. Basic non-invasive lightweight solution would be to set offset1 to 0 when bitDepth equals to 14. Another hardcore one would be to shift all MC (WP, IF...) precision on 15 bits instead of 14 bits that would be very invasive in the code. Btw, the same issue happens in HM7.0. (WP, IF). Any thoughts?" pandrivon D7 (I1003) d4 364 (Actual version: D6 dK): Where is the picture reconstruction process? Text D7 (I1003) d4 defect bbross closed 2012-02-29T16:47:40+01:00 2012-06-29T18:29:13+02:00 "The picture reconstruction process seems to have gone missing. Section 8.4.3 has these lines: ------------------------------- 4. The residual signal accumulation process as specified in subclause XXX is invoked with the variable arraySize set equal to nS, the (nS)x(nS) array predSamples, and the (nS)x(nS) array resSamples as the inputs and the output is a (nS)x(nS) array recSamples. 5. The picture reconstruction process for a component before deblocking filtering as specified in subclause XXX is invoked with the location ( xB, yB ), the variable arraySize set equal to nS, the variable cIdx set equal to 0, and the (nS)x(nS) array recSamples as the inputs and the output is a modified reconstructed picture before deblocking filtering. ------------------------------------- Section 8.5 has the same problem. There are several issues here (besides the missing sections XXXX) - The array names used as inputs and outputs are not consistent. In section 8.4.3 the array's just called 'recSamples', while in sections 8.4 and 8.5 it's identified as recSamples with subscript L, Cr and Cb (section 8.5, item 4 forgets to make a subscript of L, Cr and Cb) - The output of the picture reconstruction process is said to be 'a modified reconstructed picture'. Shouldn't this output be an array as well? The deblocking process refers to an array recPicture, but that's never defined anywhere. " hellman D7 (I1003) d4 535 Index i, j of non-square ScalingFactor matrix Text D7 (I1003) d4 defect bbross closed 2012-05-15T11:48:19+02:00 2012-06-29T18:31:41+02:00 "In 7.4.2.4 Function 7-32 is about quantization matrix of 16x4 assignment. The indexes of matrix define as ""i=0..16, j=0..4 and MatrixID=0..5"". But this matrix is 16x4, the range of i shall be 0 to 15, and range of j shall be 0 to 3. Function 7-33, 7-34, and 7-35 have the same problem." whchung D7 (I1003) d4 563 GolombDecode for ALF params does not match text ge(v) Text D7 (I1003) d4 defect bbross closed 2012-06-07T20:42:00+02:00 2012-06-29T18:32:25+02:00 "TDecCAVLC.cpp, line 922 is the signed Golomb decode function which calls the unsigned decode function xReadEpExGolomb on line 2197. This function does not match the text, or the CABAC counterpart in TDecSbac.ccp on line 285: {{{ Void TDecCavlc::xReadEpExGolomb( UInt& ruiSymbol, UInt uiCount ) { UInt uiSymbol = 0; UInt uiBit = 1; while( uiBit ) { xReadFlag( uiBit ); uiSymbol += uiBit << uiCount++; } uiCount--; while( uiCount-- ) { xReadFlag( uiBit ); uiSymbol += uiBit << uiCount; // This shift is wrong } ruiSymbol = uiSymbol; return; } }}} Text: q = −1 codeNum = 0 bit = 1 while( bit ){ bit = read_bits( 1 ) q++ } for(a = 0; a < k; ++a){ bit = read_bits( 1 ) if( bit ) codeNum += (1 << a) } codeNum += q << k ---- Below not part of the function ---- if( codeNum != 0 ) { bit = read_bits( 1 ) codeNum = ( bit ) ? codeNum : ( −codeNum ) } The function xGolombDecode on line 922 should just be re-written to match the text, and not call xReadEpExGolomb (which can just be removed all together)." pieterkapsenberg D7 (I1003) d4 570 Text / HM mismatch: intra_chroma_pred_mode partially bypass-coded Text D7 (I1003) d4 defect bbross closed 2012-06-12T13:49:59+02:00 2012-06-29T18:33:23+02:00 "TDecSbac::parseIntraDirLumaAng implements the binarization process for intra_chroma_pred_mode. Xhen decoding the last two bits, bypass decoding is used but the spec makes no mention of this. Since maxBinIdxCtx is 2 for intra_chroma_pred_mode, they should both be decoded using ""m_pcTDecBinIf->decodeBin( uiSymbol, m_cCUChromaPredSCModel.get( 0, 0, 2 ) );"" (with the same changes on the encoder side) instead." Smarter D7 (I1003) d4 583 mismatch between the WD text and the HM software on chroma deblocking Text D7 (I1003) d4 defect bbross closed 2012-06-24T16:06:25+02:00 2012-06-29T18:33:43+02:00 "In HM, the deblocking filter for chroma is applied only when bS>1. Please refer TComLoopFilter::xEdgeFilterChroma (). However, it is not clearly defined in the text. Possible solution (8.7.1.4.5 Filtering process for chroma block edge): Add the following line just after ""output of this process"". ""This process is involved when bS is greater than 1."" " suzukiyos D7 (I1003) d4 584 Mismatch between HM and Text for inter_pred_idc in the binarization and initialization process Text D7 (I1003) d4 defect bbross closed 2012-06-25T14:18:48+02:00 2012-06-25T14:48:26+02:00 "- inter_pred_idc in the initialization process was not properly set when cabac_init_flag is equal to 1 and slice_type is B in the Text. To be properly set for cabac_init_flag 0/1, the same initialization values are copied for initType 1 and 2. - inter_pred_idc in the binarization process is changed to be matched with the one mentioned in the meeting notes and implemented in HM" Tammy D7 (I1003) d4 585 Mismatch between WD and HM on inter_pred_idc Text D7 (I1003) d4 defect bbross closed 2012-06-25T14:26:15+02:00 2012-07-09T20:39:04+02:00 "- inter_pred_idc in the initialization process is not properly set when cabac_init_flag is equal to 1 in WD. Initialization table is changed in this ticket to have the same ctxIdx values for both initType 1 and 2. - inter_pred_idc in the binarization process is changed to follow the one mentioned in the meeting notes and implemented in HM." Tammy D7 (I1003) d4 591 Issue of SAO edgeIdx derivation Text D7 (I1003) d4 defect bbross closed 2012-06-26T09:43:15+02:00 2012-06-29T18:34:51+02:00 "The Sign(x) function in the text is as follows, if (x>=0), Sign(x)= 1, otherwise if (x<0), Sign(x)= -1 However, the Sign(x) function for edgeIdx should be if (x>0), Sign(x)= 1, otherwise if (x==0), Sign(x)= 0 otherwise if (x<0), Sign(x)= -1 Therefore, we should define a new Sign1(x) function for edgeIdx, edgeIdx = 2 + sum_k( Sign1( recPicture[ xC + i, yC + j ] – recPicture[ xC + i + hPos[ k ], yC + j + vPos[ k ] ] ) ) with k = 0..1 (8-350) where Sign1(x) function is as follows, if (x>0), Sign1(x)= 0, otherwise if (x==0), Sign1(x)= 0 otherwise if (x<0 ), Sign1(x)= -1 " chihming.fu D7 (I1003) d4 592 "Typo in ""7.3.4.1 Sample adaptive offset parameter syntax""" Text D7 (I1003) d4 defect bbross closed 2012-06-26T10:07:39+02:00 2012-06-29T18:35:19+02:00 "Original: sao_param( rx, ry, cIdx ){ ... if( !sao_merge_up_flag && !sao_merge_left_flag ) { ... if( sao_type_idx[ cIdx ][ rx ][ ry ] = = 5 ) { for( i = 0; i < 4; i++ ) { if( sao_offset_abs[ cIdx ][ rx ][ ry ] != 0 ) sao_offset_sign[ cIdx ][ rx ][ ry ][ i ] } } } } Fixed: sao_param( rx, ry, cIdx ){ ... if( !sao_merge_up_flag && !sao_merge_left_flag ) { ... if( sao_type_idx[ cIdx ][ rx ][ ry ] = = 5 ) { for( i = 0; i < 4; i++ ) { if( sao_offset_abs[ cIdx ][ rx ][ ry ]'''[ i ]''' != 0 ) sao_offset_sign[ cIdx ][ rx ][ ry ][ i ] } } } } " chihming.fu D7 (I1003) d4 598 Mismatch between WD and HM on end_of_slice_flag Text D7 (I1003) d4 defect bbross closed 2012-06-29T10:54:52+02:00 2012-07-14T20:08:05+02:00 "The conditions on when to parse the end_of_slice_flag syntax element in the case of slice granularities in 7.3.5 is incorrect. The current condition looks like this: {{{ if( !( ( x0 + 1 << log2CbSize ) % ( 1 << SliceGranularity ) ) && !( ( y0 + 1 << log2CbSize ) % ( 1 << SliceGranularity ) ) && NumPCMBlock = = 0 ) { }}} One problem is that x0 + 1 << log2CbSize is ambiguous Another problem is that (1 << SliceGranularity) is clearly incorrect Another problem is that end_of_slice_flag should also be parsed at the end of LCUs that are ""incomplete"" I believe these problems are all corrected if the current condition shown above is replaced by: {{{ if( (!( ( x0 + (1 << log2CbSize )) % (Log2MaxCbSize >> slice_granularity) ) || ( x0 + (1 << log2CbSize ) == pic_width_in_luma_samples) ) && (!( ( y0 + (1 << log2CbSize )) % (Log2MaxCbSize >> slice_granularity) ) || ( y0 + (1 << log2CbSize ) == pic_height_in_luma_samples) ) && NumPCMBlock = = 0 ) { }}}" rickard D7 (I1003) d4 587 Transform specification in Subclause 8.6.4.1 Text D7 (I1003) d4 enhancement bbross closed 2012-06-25T17:08:34+02:00 2012-06-25T19:36:43+02:00 "In Subclause 8.6.4.1, the inverse DST and inverse DCT are specified differently. It is suggested to harmonize the specification and specify the DST as a matrix multiply like the DCT. The text could be as follows, starting after ""- If nS is equal to 4 and trType is equal to 1, the following ordered steps apply:"" y,,i,, = ∑,,j,,( t,,ij,, * x,,j,, ) with i=0..nS−1, j=0..nS−1 t = { {29 55 74 84} {74 74 0 -74} {84 -29 -74 55} {55 -84 74 -29} } Note the indexing issue reported in #586." mwi D7 (I1003) d4 572 Subclause 0.7 text reference issue Text D7 (I1003) d4 defect bbross closed 2012-06-12T22:53:00+02:00 2012-06-29T18:36:33+02:00 "Regarding the sentence: ""Clause 6.5.6 (...) specifies the order to parse syntax elements from the bitstream."" The parentheses in this sentence copy the complete text of subclause 6.5.6 to 6.7 as a linked reference, making virtual subclauses 0.8 and 0.9. The parentheses including the copied text should be removed." mwi D7 (I1003) d5 606 Weighted prediction process needs major revision Text D7 (I1003) d5 defect bbross closed 2012-07-03T11:15:20+02:00 2012-07-11T00:01:34+02:00 "The following issues are present in the WP process 8.5.2.2.3: 1. The input ""bit-depth of the chroma component, bitDepth"" is wrong for luma invocation. 2. Variables shift1, shift2, offset1 and offset2 are derived in 8.5.2.2.3 but used in 8.5.2.2.3.1 Default weighted sample prediction process 3. The whole process is inconsistent w.r.t. luma/chroma in 8.5.2.2.3.2 Weighted sample prediction process: - there is a ""with H being replaced by Y for luma samples and by C for chroma samples"". How do we know that is is luma or chroma? - For the derivation of logWDC, o0C, o1C, and w0C, w1C, ""If C is equal to L""... Where comes C from? - Why is BitDepthC and BitDepthY used in this derivation although corresponding bitDepth is input parameter and set to the global variables when invoked? - Wouldn't it be better to pass a cIdx and derive variables depending on that variable? 4. logWDC should be log2WDC and derivation of these variable should be moved at the beginning (see #433) 5. Invocation of the WP process for chroma should be split into two paragraphs as it is done for other processes. 6. Minor improvement: Since it is not used somewhere else, ""the same as specified in sub clause 8.5.2.2.3"" should be replaced by the actual inputs and outputs. (see #433) Who is going to fix this?" bbross D7 (I1003) d5 600 recovery_frame_cnt Text D7 (I1003) d5 defect bbross closed 2012-07-01T07:20:22+02:00 2012-07-04T19:57:55+02:00 The semantic description of recovery_frame_cnt still remains in the text even though recovery_frame_cnt was already removed according to the adoption of JCTVC-I0044. kazui D7 (I1003) d5 601 semantics of temporal_id Text D7 (I1003) d5 defect bbross closed 2012-07-01T07:33:13+02:00 2012-07-04T19:57:55+02:00 The values of nal_unit_type of SPS, PPS, APS, Delimitor, Filler, and SEI used in the semantic part of temporal_id are old. Correct values are described in the attached document. kazui D7 (I1003) d6 609 significant_coeff_group_flag for 2x8 and 8x2 CGs Text D7 (I1003) d6 defect bbross closed 2012-07-04T22:17:38+02:00 2012-07-09T20:39:04+02:00 "The significant_coeff_group_flag semantics cover only diagonal scan, and do not cover horizontal (8x2 CG) and vertical (2x8 CG) scans. Corrections: For 8x2 CG, ( LastSignificantCoeffX, LastSignificantCoeffY ) should be ( 0, yCG <<1 ) For 2x8 CG ( LastSignificantCoeffX, LastSignificantCoeffY ) should be ( xCG<<1, 0 ) For 8x2 CG ( xCG, yCG ) is equal to ( 0, LastSignificantCoeffY >> 1 ) For 2x8 CG ( xCG, yCG ) is equal to ( LastSignificantCoeffX >> 1, 0 ) Thanks to C.Auyeung and B.Bross for pointing out this issue and suggesting fixes." nnguyen D7 (I1003) d6 613 Description for transform_skip_enabled_flag is not present Text D7 (I1003) d6 defect bbross closed 2012-07-10T16:19:47+02:00 2012-07-11T00:01:34+02:00 Despite the syntax element transform_skip_enabled_flag is specified (incorporated from JCTVC-I0408,the description of this syntax element is missing. shevach D7 (I1003) d7 612 "Confusion in ""6.4.5 Up-right diagonal scanning array initialization process""" Text D7 (I1003) d7 defect bbross closed 2012-07-10T12:31:33+02:00 2012-07-11T00:01:34+02:00 "In 6.4.5, the following two statements make me confuse, ""If blkWidth is less than 8 and blkHeight is less than 8"" and ""Otherwise (blkWidth is greater than 4 or blkHeight is greater than 4)"" Maybe ""less than 8"" change to ""less than or equal to 4"" is better ? " jeunder D7 (I1003) d7 614 """mvd_l1_zero_flag"" is used without definition" Text D7 (I1003) d7 defect bbross closed 2012-07-10T20:24:50+02:00 2012-07-10T23:57:40+02:00 "In I1003 D7 WD, ""mvd_l1_zero_flag"" is used in 7.3.7 Prediction unit syntax. It is a flag to determine whether the MVD from Pred_L1 is transmitted or not. However, this flag is not defined at all in the current version WD. " Feng Zou D7 (I1003) d8 615 Description of the routine alf_param() is missing Text D7 (I1003) d8 defect bbross closed 2012-07-11T09:20:14+02:00 2012-07-14T20:08:03+02:00 " In the section 7.3.2.6 the function alf_param() is called. The description of this function is missing." shevach D7 (I1003) d8 617 Significance flag semantics for 8x2 / 2x8 coefficient groups Text D7 (I1003) d8 defect bbross closed 2012-07-11T13:00:20+02:00 2012-07-14T20:08:03+02:00 "The significant_coeff_flag semantics cover only 4x4 coefficient groups, and do not cover 8×2 CG and 2×8 cases. It is assumed 4x4 coefficient groups in the following statement: – ( xC, yC ) is equal to ( xCG << 2, yCG << 2 ) " joel D7 (I1003) d8 618 Reference picture list size incorrect Text D7 (I1003) d8 defect bbross closed 2012-07-12T14:47:41+02:00 2012-07-13T11:19:54+02:00 "In section 8.3.4.2, perhaps Max( num_ref_idx_l0_active_minus1 + 1, NumPocTotalCurr ) and Max( num_ref_idx_l1_active_minus1 + 1, NumPocTotalCurr ) should have Min rather than Max." thomasd D7 (I1003) d8 619 ctxIdxInc for cbf_cb and cbf_cr may overflow Text D7 (I1003) d8 defect bbross closed 2012-07-12T15:23:31+02:00 2012-07-14T20:08:03+02:00 For a 64x64 CU and a 4x4 chroma TU, the variable trafoDepth is is 3, but the table only accounts for trafoDepth 0..2. A similar ticket on HM is filed #576 pieterkapsenberg D7 (I1003) d8 621 semantics of aps_extension_flag Text D7 (I1003) d8 defect bbross closed 2012-07-13T11:53:50+02:00 2012-07-14T20:08:05+02:00 "There are some typos in the description of aps_extension_flag semantics. ""picture"" should be replaced by ""adaptation"" as the highlighted parts. aps_extension_flag equal to 0 specifies that no aps_extension_data_flag syntax elements are present in the '''adaptation''' parameter set RBSP syntax structure. aps_extension_flag shall be equal to 0 in bitstreams conforming to this Recommendation | International Standard. The value of 1 for aps_extension_flag is reserved for future use by ITU T | ISO/IEC. Decoders shall ignore all data that follow the value 1 for aps_extension_flag in a '''adaptation''' parameter set NAL unit." chiayang_tsai D7 (I1003) d8 622 Typo in 8.3.2 Decoding process for reference picture set Text D7 (I1003) d8 defect bbross closed 2012-07-13T19:08:05+02:00 2012-07-14T20:08:03+02:00 "The sentence starting with – If the current picture is an IDR or BAL picture, should probably be – If the current picture is an IDR or BLA picture, (BLA instead of BAL)" ksuehring D7 (I1003) d9 524 transform issues Text D7 (I1003) d9 defect bbross closed 2012-05-04T17:23:40+02:00 2012-11-13T13:55:24+01:00 "1. Horizontal (row) inverse transform is carried out first and then vertical (column) inverse transform. HM does the opposite – column inverse transform first and then row inverse transform. Our understanding is that the HM reflects the intended design. 2. Core transform matrix shown 8-285 is the wrong (forward rather than inverse) transform matrix. Inverse transform matrix needs to be used instead. 3. Decision: (editorial, not relating I0428) The DST in DIS should be described in the form of matrix multiply 4. The column (or better row) addressing: - k = 1 << ( 5 – Log2( nS ) ) * i should be changed to - k = '''(''' 1 << ( 5 – Log2( nS ) ) ''')''' * i to ensure the right precedence." bbross D7 (I1003) d9 328 (Actual version: H1003_dK) A few missing items Text D7 (I1003) d9 defect bbross closed 2012-02-17T20:19:13+01:00 2012-11-30T16:00:20+01:00 "Page 26, Section 7.3.2.1 (seq_parameter_set_rbsp): scaling_list_enable_flag is missing a descriptor type. Should be u(1), I believe. Page 63: log2_diff_max_min_transform_block_size: We have assumed a maximum transform size of 32x32 for several meetings now, but I guess that never made it into the draft. This section should specify that Log2MaxTrafoSize cannot be larger than 5. As written, it allows a 64x64 transform size. Page 66: What is the range for cb/cr_qp_offset? Based on their use, I would think it would be like that of pic_init_qp_minus26 (-26 to +25 for 8-bit video). Page 73: No range given for max_transform_hierarchy_depth_intra/inter. Seems like it should relate to log2_diff_max_min_transform_block_size Page 76: No range given for beta_offset_div2 or tc_offset_div2. Equivalent variables in AVC had a range of -6 to +6. " hellman D7 (I1003) d9 349 part_mode parsing Text D7 (I1003) d9 defect bbross closed 2012-02-29T07:17:35+01:00 2012-11-30T16:00:20+01:00 "(actual version dK) In 7.4.2.1, we have asymmetric_motion_partitions_enabled_flag. The parsing of part_mode should depend on that flag. In HM, when that flag is 0, the AMP bins are not parsed. But in the draft, Table 9-34, the parsing of part_mode does not depend on that flag." libin D7 (I1003) d9 627 Inferring split_transform_flag: mismatch between HM 7.1 and D9 (I1003) d9 Draft Text Text D7 (I1003) d9 defect bbross closed 2012-07-19T08:58:35+02:00 2012-11-30T16:00:20+01:00 "Hi, HM 7.1 decoder seems to use log2MinTUSizeInCU (derived from UInt TComDataCU::getQuadtreeTULog2MinSizeInCU) to decide whether split_transform_flag needs to be inferred or parsed from the bitstream, but in I1003-d9 Draft Log2MinTrafoSize (SPS level parameter) is used directly to decide whether split_transform_flag is inferred or parsed from the bitstream as follows: if( log2TrafoSize <= Log2MaxTrafoSize && log2TrafoSize > Log2MinTrafoSize && trafoDepth < MaxTrafoDepth && !(IntraSplitFlag && trafoDepth = = 0) ) split_transform_flag[ x0L ][ y0L ][ trafoDepth ] For example, if LCU=32x32, log2cbsize=5, log2trafosize=5, Log2MaxTrafoSize=5, Log2MinTrafoSize=4, MaxtrafoDepth=1, part_mode=2Nx2N, pred_mode_flag=Intra, trafoDepth=0 HM 7.1 decoder computes log2MinTUSizeInCU as 5 and infers the split_transform_flag as 0 (with out parsing the split_transform_flag from the bit stream). However based on the I1003-d9 Draft text, split_transform_flag is parsed from the bit stream in this case. Can you please clarify whether the Draft text needs to be fixed? Thanks, -Hari " hreddy D7 (I1003) d9 629 Change in semantics of entry_point_offset[ i ] to disallow putting no entry points in the presence of tiles/wpp Text D7 (I1003) d9 defect bbross closed 2012-07-19T19:39:02+02:00 2012-11-30T16:00:20+01:00 "It was decided during last Geneva meeting that each tile should have an entry point. It was also always agreed since the adoption of WPP that each substream should have an entry point. However, a bitstream with multiple tiles or WPP can have zero entry points while conforming to the current spec. A straightforward correction is proposed below. Proposed text correction in the semantics of '''entry_point_offset'''[ i ]: When tiles_or_entropy_coding_sync_idc is equal to 1 ~~and num_entry_point_offsets is greater than 0~~, each subset shall contain all coded bits of exactly one tile, and the number of subsets (i.e., the value of num_entry_point_offsets + 1) shall be equal to the number of tiles in the slice. […] When tiles_or_entropy_coding_sync_idc is equal to 2 ~~and num_entry_point_offsets is greater than 0~~, each subset k with k in the range of 0 to num_entry_point_offsets − 1, inclusive, shall contain all coded bits of exactly one row of coding tree blocks, […]. " felix.henry D7 (I1003) d9 630 transform_tree xBase and yBase should be previous x0C and y0C Text D7 (I1003) d9 defect bbross closed 2012-07-19T22:23:49+02:00 2012-11-30T16:00:20+01:00 "In the WD, transform_tree is recursively called with: {{{ transform_tree( x0L, y0L, x0C, y0C, x0L, y0L, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 0 ) transform_tree( x1L, y1L, x1C, y1C, x0L, y0L, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 1 ) transform_tree( x2L, y2L, x2C, y2C, x0L, y0L, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 2 ) transform_tree( x3L, y3L, x3C, y3C, x0L, y0L, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 3 ) }}} Which mean that in the called functions, we have xBase = x0L and yBase = y0L, but these function arguments are used for chroma elements, like cbf_cb[ xBase ][ yBase ][ trafoDepth − 1 ], so we should have xBase = x0C and yBase = y0C, and the recursive calls should be changed to: {{{ transform_tree( x0L, y0L, x0C, y0C, x0C, y0C, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 0 ) transform_tree( x1L, y1L, x1C, y1C, x0C, y0C, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 1 ) transform_tree( x2L, y2L, x2C, y2C, x0C, y0C, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 2 ) transform_tree( x3L, y3L, x3C, y3C, x0C, y0C, log2CbSize, log2TrafoWidth − 1, log2TrafoHeight − 1, trafoDepth + 1, 3 ) }}}" Smarter D7 (I1003) d9 631 missing value in ctxIdxMap Text D7 (I1003) d9 defect bbross closed 2012-07-19T23:15:32+02:00 2012-11-30T16:00:20+01:00 "The ctxIdxMap in Table 9-70 used for the derivation of ctxIdxInc for significant_coeff_flag in section 9.3.3.1.4 does not define ctxIdxMap[15], but this value is needed, for example if xC = 6, yC = 6, log2TrafoWidth = 3, log2TrafoHeight = 3, then: sigCtx = ((xC + yC) = = 0) ? 0 : ( 9 + ctxIdxMap[ ((yC >> 1 ) << 2) + (xC >> 1) ] ) sigCtx = 9 + ctxIdxMap[15] In the HM, the equivalent map is ctxIndMap and ctxIndMap[15] = 8." Smarter D7 (I1003) d9 632 derivation of significant_coeff_group_flag ctxIdxInc does not handle non-square CG Text D7 (I1003) d9 defect bbross closed 2012-07-20T00:20:08+02:00 2012-11-30T16:00:20+01:00 "The value of ctxCG in Section 9.3.3.1.3 is incorrect for 8x2 and 2x8 coefficient groups, to be correct it should be equivalent to: {{{ if (log2TrafoWidth == 3 && log2TrafoHeight == 3 && scanIdx != 0) { if (scanIdx == 1) { if (yCG < 3) ctxCG += significant_coeff_group_flag[xCG][yCG + 1]; } else { //scanIdx == 2 if (xCG < 3) ctxCG += significant_coeff_group_flag[xCG + 1][yCG]; } } else { if (xCG < (1 << (log2TrafoWidth - 2)) - 1) ctxCG += significant_coeff_group_flag[xCG + 1][yCG]; if (yCG < (1 << (log2TrafoHeight - 2)) - 1) ctxCG += significant_coeff_group_flag[xCG][yCG + 1]; } }}}" Smarter D7 (I1003) d9 636 cRiceParam mismatch between HM7.1 and Draft I1003-d9 Text D7 (I1003) d9 defect bbross closed 2012-07-21T08:25:33+02:00 2012-11-30T16:00:20+01:00 "Hi, Issue 1: cRiceParam is updated as follows in the HM7.1 model (which matches with I0124_r2) #if SIMPLE_PARAM_UPDATE if(uiLevel > 3*(1<(uiGoRiceParam+ 1, 4); } #else In the current Draft text, cRiceParam is specified as follows (>= should be replaced by > in the following equation) cRiceParam = Min( cLastRiceParam + ( cLastAbsLevel >= ( 3 * ( 1 << cLastRiceParam ) ) ) ? 1 : 0, 4 ) -- (9 10) Issue 2 (text wording): In the same section (9.3.2.8), cLastSE and cLastAbsLevel are used interchangeably. We should either use cLastAbsLevel or cLastSE consistently throughout the section. " hreddy D7 (I1003) d9 639 Vertical and horizontal modes in 8.4.3.1.4 Text D7 (I1003) d9 defect bbross closed 2012-07-24T15:04:07+02:00 2012-11-30T16:00:20+01:00 "(Note: section number has changed in draft 8, to 8.4.4.2.6) One input to this section is cIdx, but it is never used. Perhaps it is meant to be used in the sub-numbered items 2.c., which have equations (8-48 and 8-56) that use the function Clip1Y(). If the additional condition (cIdx > 0) is applied to items 2.c., then the intra angular modes 10 and 26 will be the same as they were for previous versions of the spec (before D7(I1003) d9)." wwlin D7 (I1003) d9 641 part_mode PART_2NxN bin string issue Text D7 (I1003) d9 defect bbross closed 2012-07-24T20:15:21+02:00 2012-10-11T04:27:05+02:00 In table 9-36 Binarization for part_mode, PART_2NxN bin string 011 dose not match HM7.1 at column cLog2CbSize > Log2MinCbSize. The bin string should be 01. exf001 D7 (I1003) d9 642 entropy_coding_reset_flag undefined Text D7 (I1003) d9 defect bbross closed 2012-07-25T19:33:57+02:00 2012-11-30T16:00:20+01:00 entropy_coding_reset_flag also undefined in section 9.3 of latest DIS draft: JCTVC-J1003_d3.doc (July 24). chadfogg D7 (I1003) d9 710 Typo in the section 8.5.2.1.2 Derivation process for spatial merging candidates Text D7 (I1003) d9 defect bbross closed 2012-09-02T13:30:25+02:00 2012-09-04T11:32:34+02:00 "In the section 8.5.2.1.2 ""Derivation process for spatial merging candidates"" is written the following statement: If one or more of the following conditions are true with X being replaced by 0 and 1, the availableFlagN is set equal to 0, both components mvLXN are set equal to 0, refIdxLXN and predFlagLX[ xN, yN ] of the prediction block covering luma location ( xN, yN ) are assigned respectively to mvLXN, refIdxLXN and predFlagLXN. The second appearence of mvLXN is apparently typo, since mvLXN already set to zero." shevach D7 (I1003) d9 634 Derivation of intra luma mode predictors when neighbor is I_PCM. Text D7 (I1003) d9 enhancement bbross closed 2012-07-20T12:45:45+02:00 2012-11-30T16:00:20+01:00 "The intra_prediction mode of I_PCM is defined as DC in HM software. It would be better to define intra_prediction mode of I_PCM explicitly in the text as well. Attachment is suggested editorial enhancement to the current text (JCTVC-I1003_d9). Changes are as follows: 1. Add index to pcm_flag in 7.3.6. Coding unit syntax. 2. Add one condition in ""8.4.1 Derivation process for luma intra prediction mode. " kchono D7 (I1003) d9 637 Typos in 9.3 CABAC parsing process for slice Text D7 (I1003) d9 task bbross closed 2012-07-21T20:11:05+02:00 2012-11-30T16:00:20+01:00 "In the last paragraph of ""9.3 CABAC parsing process for slice data"", the referred subsection number ""9.3.1.2"" is not correct. It should be ""9.3.1.4."" And also, ""pcm-flag"" should be ""pcm_flag"". These typos should be fixed. In addition, it is suggested that two related sentences in 9.3.1.4 and 9.3.4.1 are improved. Specifically, all conditions for initializing arithmetic decoding/encoding engine should be described. " kchono D7 (I1003) d9 586 Matrix index xy or yx: swapped in Subclauses 8.6.3 and 8.6.4 Text D7 (I1003) d9 defect bbross closed 2012-06-25T16:56:29+02:00 2012-11-30T16:00:20+01:00 "In Subclause 5.9, the definition is: ""An element of a matrix s at horizontal position x and vertical position y may be denoted either as s[ x, y ] or as s,,yx,,."" In Subclauses 8.63 and 8.6.4, matrices c,,ij,, d,,ij,, e,,ij,, m,,ij,, etc are used with i referring to the horizontal and j referring to the vertical position. Either the definition in Subclause 5.9 or the indices in 8.6.x should be changed. " mwi D7 (I1003) d9 616 Output missing in 8.6.1, minor text corrections in 8.6.2 Text D7 (I1003) d9 defect bbross closed 2012-07-11T11:35:21+02:00 2012-11-30T16:00:20+01:00 "In the rewritten version of subclause 8.6.1 ""Derivation process for quantization parameters"", the output of the process is missing (should be QP',,Y,,, QP',,Cb,,, QP',,Cr,,). Some minor text corrections for subclause 8.6.2 are provided in the attached doc." mwi D7 (I1003) d9 624 prev_intra_pred_flag should be prev_intra_luma_pred_flag Text D7 (I1003) d9 defect bbross closed 2012-07-14T20:32:46+02:00 2012-11-30T16:00:20+01:00 "Rename this in ""8.4.1 Derivation process for luma intra prediction mode.""" bbross D7 (I1003) d9 625 Level 2 MaxBR and Max CPB Size not updated Text D7 (I1003) d9 defect bbross closed 2012-07-14T20:42:07+02:00 2012-11-30T16:00:20+01:00 "For Level 2 MaxBR and Max CPB Size has been changed to 1500 according to the table in the Geneva meeting notes under: ""Decision: Update table as follows:""" bbross D8 (J1003) d7 684 Weighted Prediction Formula Bug in 8.5.2.2.3.2 Weighted sample prediction process Text D8 (J1003) d7 defect bbross closed 2012-08-21T19:32:37+02:00 2012-11-30T16:00:20+01:00 "In Section 8.5.2.2.3.2 Weighted sample prediction process, Equations (8-227) and (8-229), predSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) − 1, predSamplesL0[ x ][ y ] * w0 + o0 ) (8-227) predSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) − 1, predSamplesL1[ x ][ y ] * w1 + o1 ) (8-229) have fatal errors that predSamplesL0 and predSamplesL1 are not right-shifted by ""shift1"". Those errors result in predSamples are always equal to ( 1 << bitDepth ) − 1. The correct equations are given as follows: predSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) − 1, (predSamplesL0[ x ][ y ] + offset1 ) >> shift1 ) * w0 + o0 ) (8-227) predSamples[ x ][ y ] = Clip3( 0, ( 1 << bitDepth ) − 1, (predSamplesL1[ x ][ y ] + offset1 ) >> shift1 ) * w1 + o1 ) (8-229)" yul D8 (J1003) d7 743 Deblocking filter : neighboring information Text D8 (J1003) d7 technical change bbross closed 2012-09-13T14:46:28+02:00 2012-11-30T16:51:38+01:00 " In chapter 8.7.2.3 : ""derivation process of boundary filtering strength"" of JCTVC-J1003_d7, we need to keep some prediction block informations to determine the bS of the current prediction block boundary : for example : prediction mode (inter/intra) , PartMode, motion vectors and reference pictures. Let's consider the case where the current boundary is a prediction block boundary, and q0 and p0 are both coded with inter prediction. ====== For horizontal edge, if p0 and q0 do not belong to the same coding tree block (CTB), we may use another p0, not necessarily the top neighbor of q0 (See attached schematics): ""– When edgeType is equal to EDGE_HOR and yC + yDj − 1 is less than (( yC >> Log2CtbSizeY ) << Log2CtbSizeY), sample p0 = recPictureL[ xL ][ yC + yDj – 1 ] where xL is equal to ((( xC + xDi ) >> 3) << 3) + ((( xC + xDi ) >> 3) & 1) * 7"" My understanding is that, if we consider a deblocking process that works on picture CTB row basis, we only need to have from the top CTB row, at most 2 prediction block information per 16 pixel of horizontal boundary (instead of 4 at most). This is done to reduce bandwidth. ====== The current deblocking function has been optimized, in terms of bandwidth, for a CTB process in picture raster scan. This scan order is not the order used in the other functions of chapter 8. The intention of our proposal is to reduce bandwidth when we are doing the deblocking filter in tile scan order (i.e. the same order as the other functions). The proposed idea is the same as the one used for horizontal edge. Our proposal (to be done after the previous point on horizontal edge): - When edgeType is equal to EDGE_VER and TileId[ctbAddrTS_p0] is different from TileId[ctbAddrTS_q0], sample p0 = recPictureL[ xC + xDi - 1 ][ yL ] where : yL = ((( yC + yDj ) >> 3) << 3) + ((( yC + yDj ) >> 3) & 1) * 7 ctbAddrTS_p0 = ctbAddrRStoTS[ ctbAddrRS_p0 ] ctbAddrRS_p0 = ((xC + xDi -1) >> Log2CtbSize) + ((yC + yDj) >> Log2CtbSize) * PicWidthInCtbsY ctbAddrTS_q0 = ctbAddrRStoTS[ ctbAddrRS_q0 ] ctbAddrRS_q0 = ((xC + xDi) >> Log2CtbSize) + ((yC + yDj) >> Log2CtbSize) * PicWidthInCtbsY Note : this could also be done for slice vertical boundaries. Note that a slice vertical boundary that does not coincide with a tile boundary is only 1 CTB high. Note 2 : In this proposal we do not take into account the potential quality loss on tile boundaries." Jing-Jing Chung D8 (J1003) d7 648 Incorrect derivation process of ctxIdxInc for the syntax element significnat_coeff_flag Text D8 (J1003) d7 defect bbross closed 2012-07-31T07:13:36+02:00 2012-07-31T07:25:13+02:00 "In ""9.3.3.1.4 Derivation process of ctxIdxInc for the syntax element significant_coeff_flag"", there is a mismatch ('''bold type''') on eq.(9-26) between D8/J1003 d7 and HM7.2-dev(r2666). According to HM7.2-dev(r2666) or the adopted text of JCTVC-J0256, the offset value on 8x8TU is dependent on the scanIdx in both luma and chroma as follows; TComTrQuant.cpp::Int TComTrQuant::getSigCtxInc(...) { ... Int offset = '''blockType == 3 ? (scanIdx==SCAN_DIAG ? 9 : 15)''' : (textureType == TEXT_LUMA ? 21 : 12); ...} However, in D8/J1003 d7 eq.(9-26) is not matched with the above. –The variable sigCtx is modified as follows. –If cIdx is equal to 0, the following applies. ... –If log2TrafoSize is equal to 3, the following applies. sigCtx += ( scanIdx = = 0 ) ? 9 : 15 (9-24) ... –Otherwise (cIdx is greater than 0), the following applies. –If log2TrafoSize is equal to 3, the following applies. '''sigCtx += 9 (9-26)''' ... So, eq.(9-26) should be modified as follows; '''sigCtx += ( scanIdx = = 0 ) ? 9 : 15'''" tsukuba D8 (J1003) d7 649 num_tile_columns_minus1, num_tile_rows_minus1 Text D8 (J1003) d7 defect bbross closed 2012-07-31T10:54:06+02:00 2012-09-19T11:06:41+02:00 "In document JCTVC-JI003_d3, num_tile_columns_minus1, num_tile_rows_minus1 have no default value when not present in the bitstream (i.e. when tiles_enable_flag=0). I assume that the default value is 0 for both. The comment in num_tile_rows_minus1 definition : ""When num_tile_columns_minus1 is equal to 0, num_tile_rows_minus1 shall not be equal to 0."" has then to be modified, taking into account tiles_enable_flag. " chung D8 (J1003) d7 653 Missing statement in 8.7.2.3 derivation of boundary filtering strength Text D8 (J1003) d7 defect bbross closed 2012-08-02T10:45:00+02:00 2012-09-12T13:05:15+02:00 "In 8.7.2.3 derivation of boundary filtering strength, ""Otherwise, if the block edge is also a transform block edge and the sample p0 or q0 is in a luma transform block which contains non-zero transform coefficient level'''.'''"" should be replaced by ""Otherwise, if the block edge is also a transform block edge and the sample p0 or q0 is in a luma transform block which contains non-zero transform coefficient level''', the variable bS[xDi][yDj] is set equal to 1.'''"" " djpark0115 D8 (J1003) d7 654 Several references to disable_deblocking_filter_flag Text D8 (J1003) d7 defect bbross closed 2012-08-02T18:29:06+02:00 2012-09-12T12:58:47+02:00 "In 8.7.2 - Deblocking Filter Process, and in the slice sytnax table, there are references to a non-existing sytnax element disable_deblocking_filter_flag. Rather it could be changed to a variable called disableDeblockingFilterFlag that is set equal to {{{ pps_disable_deblocking_filter_flag || slice_header_disable_deblocking_filter_flag }}} in the semantics" pieterkapsenberg D8 (J1003) d7 656 Access Invalid index of MinTbAddrZS Text D8 (J1003) d7 defect bbross closed 2012-08-03T07:13:23+02:00 2012-09-12T12:54:42+02:00 "In 7.4.2.3 Picture parameter set RBSP semantics, indexes of array MinTbAddrZS are defined inside picture boundary. But, in 6.4.1 Derivation process for z-scan order block availability, index can be outside picture boundary when minBlockAddrN is calculated. " djpark0115 D8 (J1003) d7 657 inconsistent capitalization of ctbAddrRStoTS Text D8 (J1003) d7 defect bbross closed 2012-08-04T04:47:30+02:00 2012-10-04T14:48:54+02:00 ctbAddrRStoTS and CtbAddrRStoTS are present in the text and appear to refer to the same entity. It is suggested to change all occurrences of ctbAddrRStoTS to CtbAddrRStoTS. dthoang D8 (J1003) d7 660 In subclause 8.7.2.3, one sentence to set boundary strength equal to 1 is missing Text D8 (J1003) d7 defect bbross closed 2012-08-07T10:27:15+02:00 2012-08-07T12:13:46+02:00 "In subclause 8.7.2.3, the description ""the bS[ xDi ][ yDj ] is set equal to 1"" should be added after the following condition: – Otherwise, if the block edge is also a transform block edge and the sample p0 or q0 is in a luma transform block which contains non-zero transform coefficient level. " jicheng D8 (J1003) d7 663 miscellaneous typos Text D8 (J1003) d7 defect bbross closed 2012-08-08T00:56:28+02:00 2012-09-11T16:00:43+02:00 "The typo ""for for"" appears twice: first in the semantics of '''vps_temporal_id_nesting_flag''' and then in semantics of '''general_reserved_zero_16bits'''. The typo ""the the"" appears twice: first in 8.5.2.1 and then in 9.3.3.1.4. Preceding is misspelled as ""preceeding"" in semantics of '''dependent_slice_flag'''. " dthoang D8 (J1003) d7 664 ctxIdxMap table is missing an entry Text D8 (J1003) d7 defect bbross closed 2012-08-08T03:25:32+02:00 2012-08-08T06:28:56+02:00 In 9.3.3.1.4 it is possible to index table 9-39, ctxIdxMap[i] with i=15. This column is missing from the text. In HM the resulting value of ctxIdxMap[15] is 8. pieterkapsenberg D8 (J1003) d7 665 Checking constrained_intra_pred_flag is missing Text D8 (J1003) d7 defect bbross closed 2012-08-08T04:53:44+02:00 2012-09-12T12:10:06+02:00 "In 8.4.4.2.1 General intra sample prediction, ""PredMode[ xBN ][ yBN ] is not equal to MODE_INTRA"" should be replaced by ""PredMode[ xBN ][ yBN ] is not equal to MODE_INTRA and constrained_intra_pred_flag is equal to 1"" This bug started from j1003_d6. " djpark0115 D8 (J1003) d7 668 HM8/WD mismatch for coeff_abs_level_greater1_flag context derivation Text D8 (J1003) d7 defect bbross closed 2012-08-08T18:01:42+02:00 2012-09-12T12:01:47+02:00 "In the WD, 9.3.3.1.5 the following appears: – If this process is invoked for the first time for the current sub-block scan index i, the following applies. - .... - The variable lastGreater1Ctx is derived as follows. - If the current sub-block with scan index i is the first one to be processed in this subclause for the current transform block, the variable lastGreater1Ctx is '''set equal to 0.''' However, in HM-8.0 TDecSbac::parseCoeffNxN, line 1227: {{{ #if REMOVE_NUM_GREATER1 UInt c1 = 1; }}} Looks like the init here is 1, instead of 0 like the text says. " pieterkapsenberg D8 (J1003) d7 672 coded_sub_block_flag semantics Text D8 (J1003) d7 defect bbross closed 2012-08-13T20:36:48+02:00 2012-09-11T15:14:36+02:00 "Problems: 1. The term “sub-block” is not clearly defined. The clause “which is an array of 16 transform coefficient levels at locations ( xC, yC )” refers to the the transform block, not the sub-block, and is incorrect. Moreover, “(xC, yC)” is not referenced in the coded_sub_block_flag semantics and is not needed. 2. There is a missing comma in “( xS, yS ) is equal to ( LastSignificantCoeffX >> 2 LastSignificantCoeffY >> 2 )” Proposed Fixes: 1. Indicate that the sub-block is 4x4 and remove the clause “which is an array of 16 transform coefficient levels at locations ( xC, yC )” since it is not needed 2. Add the missing comma " nnguyen D8 (J1003) d7 677 Typo in 9.3.2.7 about binarization process for coeff_abs_level_remaining Text D8 (J1003) d7 defect benjamin.bross@… closed 2012-08-17T03:20:54+02:00 2012-09-11T15:01:49+02:00 "In Subclause9.3.2.7, page 173 of document JCTVC-J1003_d7: Typo description: –Otherwise ( n is less than 15 ), cLastAbsLevel is set equal to baseLevel + coeff_abs_level_remaining[ n − 1 ] and cLastRiceParam is set equal to the value of cRiceParam that has been derived during the invocation of the binarization process as specified in this subclause for the syntax element coeff_abs_level_remaining[ n − 1 ] of the same transform block. Update description: –Otherwise ( n is less than 15 ), cLastAbsLevel is set equal to baseLevel + coeff_abs_level_remaining[ n + 1 ] and cLastRiceParam is set equal to the value of cRiceParam that has been derived during the invocation of the binarization process as specified in this subclause for the syntax element coeff_abs_level_remaining[ n + 1 ] of the same transform block. Thanks to Benjamin's kindly help on such typo confirm and track system using." vikingwang@… D8 (J1003) d7 679 scaling_list_dc_coef_minus8 has no default value Text D8 (J1003) d7 defect bbross closed 2012-08-17T22:47:40+02:00 2012-09-11T14:59:25+02:00 When a scaling list is not explicitly parsed for 16x16 or 32x32, or if the default is specified, the syntax element scaling_list_dc_coef_minus8 isn't present. Yet in the Scaling List Semantics where the ScalingFactor array is derived, scaling_list_dc_coef_minus8 is used anyway. The text here should be corrected. The simplest solution is to just assume the default dc coefficient is 16 (this matches HM), so scaling_list_dc_coef_minus8 is inferred to be 8 when not present. pieterkapsenberg D8 (J1003) d7 683 Typos in 7.4.5.1 and 9.3.2 Text D8 (J1003) d7 defect bbross closed 2012-08-21T14:53:07+02:00 2012-09-11T14:30:12+02:00 "Two typos are found. In semantics of mvd_l1_zero_flag in 7.4.5.1; ""compIdx=0..2"" should be ""compIdx=0..1"". In 4th paragraph in 9.3.2(The specification of the unary (U) binarization process...); ""subclauses 9.3.2.10 to 9.3.2.5"" should be ""subclauses 9.3.2.1 to 9.3.2.5"". " suzukiyos D8 (J1003) d7 689 Typos, etc in Subclause 8.7.2 Deblocking filter process Text D8 (J1003) d7 defect bbross closed 2012-08-23T12:31:24+02:00 2012-09-11T14:16:11+02:00 "Subclauses 8.7.2.1 and 8.7.2.2: * The order of EDGE_VER and EDGE_HOR in the specification differs from the other subclauses - flip. Subclause 8.7.2.4.3: * Rename to ""Decision process for luma block edge/s/"" * Output: ""- /the/ variables dE, ..."", ""- /the/ variables beta, tC"" * Table 8-10 should be moved from 8.7.2.4.7 to this subclause Subclause 8.7.2.4.4: * Rename to ""Filtering process for luma block edge/s/"" Subclause 8.7.2.4.5: * Rename to ""Filtering process for chroma block edge/s/"" * Formatting in e q.(8-297): p_{i,k} should have subscript indices Subclause 8.7.2.4.7: * Input is the variable t_C, in the following text, tc is used. " mwi D8 (J1003) d7 691 'deblocking_filter_overide_flag' in slice header Text D8 (J1003) d7 defect bbross closed 2012-08-23T14:25:51+02:00 2012-09-11T13:53:35+02:00 "In section ‘7.4.5.1 General slice header semantics’ of JCTVC-J1003_d7.doc, it is currently defined as;- '''deblocking_filter_override_flag''' equal to 0 specifies that deblocking parameters from the active picture parameter set are used for deblocking the current slice. deblocking_filter_override_flag equal to 0 specifies that deblocking parameters from the slice header are used for deblocking the current slice. When not present, the value of deblocking_filter_override_flag is inferred to be equal to 1. Initially I thought there was a simple typo in the second sentence which should have said;- deblocking_filter_override_flag equal to '''1''' specifies that deblocking parameters from the slice header are used for deblocking the current slice. However, looking at the HM decode software, it appears to treat the flag as ‘inherit_dbl_param_from_PPS_flag’ which is the opposite sense to the override flag. (Where it does not code the filter coefficients if the flag in the bitstream is 1, and the flag defaults to 0 if ‘deblocking_filter_override_enabled_flag’ is low). At the moment I'm just entering this as a Text bug, because I don't know if the text wants to change to match the sense of the flag in HM, or whether the sense of the bit in HM also needs to change. " agoudie D8 (J1003) d7 693 Typos, etc in Subclause 7.4 Text D8 (J1003) d7 defect bbross closed 2012-08-27T12:40:17+02:00 2012-09-12T11:17:40+02:00 "Subclause 7.4.1.4.3 * Constraint for FD_NUT not to precede the first VCL NAL unit appears twice, the second version can be deleted. Subclause 7.4.2.3 * Derivation of MinTbAddrZS: y should range from 0 to ( Pic**Height**InCtbsY << (Log2CtbSizeY − Log2MinTrafoSize) ) − 1 Subclause 7.4.5.3 * RefPicSetCurrTempList0 and RefPicSetCurrTempList1 only appear here, rename to RefPicListTemp0 and RefPicListTemp1 as used in 8.3.4.2 " mwi D8 (J1003) d7 699 Derivation process of chroma offset in WP when an input bit depth is beyond 8bit Text D8 (J1003) d7 defect bbross closed 2012-08-29T02:22:33+02:00 2012-09-11T11:48:20+02: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 equation (7-48) in section 7.4.5.4 should be modified simply as follows: --------- '''Original;''' shift = 1 << ( BitDepthC − 1 ) ChromaOffsetL0[ i ][ j ] = Clip3( −128, 127, (delta_chroma_offset_l0[ i ][ j ] – ( (shift*ChromaWeightL0[ i ][ j ]) >> ChromaLog2WeightDenom ) − shift ) ) (7-48) --------- '''Modified;''' ChromaOffsetL0[ i ][ j ] = Clip3( −128, 127, (delta_chroma_offset_l0[ i ][ j ] – ( (128*ChromaWeightL0[ i ][ j ]) >> ChromaLog2WeightDenom ) − 128 ) ) (7-48) " Tanizawa D8 (J1003) d7 702 8.5.2.1.6 confusing phantom equations Text D8 (J1003) d7 defect bbross closed 2012-08-29T15:04:12+02:00 2012-09-11T11:34:46+02:00 "In 8.5.2.1.6, when deriving mvLXB and availableFlagLXB, the step 2 specifies the condition to modify xBk by equations 8-131 to 8-133. [[BR]] However, in the following step 4 and 6, xBk's are again set to the values specified in step 1 (say, xB0 = xP + nPbW, xB1 = xB0 − 1, and xB2 = xP − 1). This makes step2 phantom modification." conrad.ho D8 (J1003) d7 705 typo for upCtbInSlice derivation in subclause7.3.7.1 (page42) Text D8 (J1003) d7 defect bbross closed 2012-08-30T10:47:14+02:00 2012-09-11T11:23:54+02:00 "The typo and corresponding correction in subclause7.3.7.1 (page42)for upCtbInSlice derivation are as follows: Typo description: upCtbInSlice = ( CtbAddrTS – CtbAddrRStoTS[CtbAddrRS − PicWidthInCtbsY] ) <= CtbAddrInSlice Corrected description: upCtbInSlice = (CtbAddrRS − PicWidthInCtbsY) >= slice_address Thanks to Benjamin's kindly help on it. " vikingwang@… D8 (J1003) d7 706 No definition of Log2MaxCtbSize Text D8 (J1003) d7 defect bbross closed 2012-08-30T14:08:33+02:00 2012-09-12T10:52:40+02:00 "The variable Log2MaxCtbSize is used in (a) the definition of max_transform_hierarchy_depth_inter and max_transform_hierarchy_depth_intra, and (b) A.4.2 sub-item f. However, Log2MaxCtbSize is not defined.[[BR]] For (a), the suggestion is replacing Log2MaxCtbSize by Log2MaxTrafoSize.[[BR]] For (b), the suggestion is replacing Log2MaxCtbSize by Log2CtbSizeY." conrad.ho D8 (J1003) d7 708 An error in WD for ctxIdxInc for the syntax element significant_coeff_flag Text D8 (J1003) d7 defect bbross closed 2012-08-30T17:57:01+02:00 2012-09-11T12:35:20+02:00 "The description before equation (9-17) – When xS is less than ( 1 << log2TrafoSize − 2 ) − 1, the following applies. prevCsbf += coded_sub_block_flag[ xS + 1 ][ yS ] (9 17) should be change to – When xS is less than ( 1 << (log2TrafoSize − 2) ) − 1, the following applies." exf001 D8 (J1003) d7 711 chroma deblocking filter position Text D8 (J1003) d7 defect bbross closed 2012-09-04T07:08:03+02:00 2012-09-19T16:06:31+02:00 "In 8.7.2.4.1 Vertical edge filtering process, chroma edges filtering is described as follows 1. The variable nD is set equal to 1 << ( Max( log2CbSize, 4 ) − 4 ). 2. For xDk set equal to (xC/2)+(k << 3), k=0..nD − 1, the following applies. For yDm set equal to (yC/2)+(m << 2), m=0..nD*2 − 1, the following applies When log2CbSize is 3, nD is 1 and (xDk, yDm) is (xC/2, yC/2), (xC/2, yC/2+4) It makes two problems. 1. When (xC / 2) is not multiple of 8, the chroma edge is filtered. but it is not matched with HM8.0 2. (xC/2, yC/2+4) is invalid filtering position because chroma ctb is 4x4 Horizontal chroma filtering has also the same problem." djpark0115 D8 (J1003) d7 718 Typo in subclause 6.4.1 Text D8 (J1003) d7 defect bbross closed 2012-09-05T08:01:36+02:00 2012-09-11T10:12:55+02:00 "In 6.4.1 Derivation process for z-scan order block availability, the following descriptions, ---- The neighbouring block availability availableN is derived as follows. ... – the variable BaseSliceAddrRS associated with the slice containing the coding block with minimum coding block address minBlockAddrCurr differs in value from the variable BaseSliceAddrRS associated with the slice containing the coding block with the current minimum coding block address. ... ---- should be modified to ---- The neighbouring block availability availableN is derived as follows. ... – the variable BaseSliceAddrRS associated with the slice containing the coding block with minimum '''luma''' block address '''minBlockAddrN''' differs in value from the variable BaseSliceAddrRS associated with the slice containing the coding block with the current minimum '''luma''' block address '''minBlockAddrCurr'''. " chiayang_tsai D8 (J1003) d7 719 Mistake in 8.4.3. table 8-2 : derivation process for chroma intra prediction mode Text D8 (J1003) d7 defect bbross closed 2012-09-05T10:44:44+02:00 2012-09-11T10:13:31+02:00 "The table 8-2 does not specify the value of IntraPredModeC for IntraPredMode[xB][yB]=34. The condition of the last column could be changed into : (0<=X'''<='''34) " Jing-Jing Chung D8 (J1003) d7 721 8.6.1 tiles_or_entry_coding_sync_idc used Text D8 (J1003) d7 defect bbross closed 2012-09-05T15:03:36+02:00 2012-09-11T09:40:15+02:00 "In 8.6.1, text said: ""The current quantization group is the first quantization group in a coding tree block row and tiles_or_entry_coding_sync_idc is equal to 2."" [[BR]] But tiles_or_entry_coding_sync_idc is not defined.[[BR]] Suggestion: Replace ""tiles_or_entry_coding_sync_idc is equal to 2"" by ""entropy_coding_sync_enabled_flag is equal to 1"" " conrad.ho D8 (J1003) d7 722 "8.5.2.1.7 : Collocated derivation, Confusing reference to ""every"" reference picture list." Text D8 (J1003) d7 defect bbross closed 2012-09-05T17:37:10+02:00 2012-09-11T09:21:14+02:00 "In chapter 8.5.2.1.7, mvCol, refIdxCol and listCol are derived according to following sentence: ""If PicOrderCnt( pic ) of every picture pic in every reference picture lists is less than or equal to PicOrderCntVal"" ""Every reference picture lists"" may refer to 1) picture lists L0 and L1 associated to the current luma prediction block 2) picture lists L0 and L1 associated to the collocated luma prediction block" AlexisLefebvre D8 (J1003) d7 724 Loop in RasterScan to TileScan lacks an early exit Text D8 (J1003) d7 defect bbross closed 2012-09-06T03:29:13+02:00 2012-09-07T00:16:35+02:00 "In '''6.5.1 Coding tree block raster and tile scanning conversion process''', the derivation process for ctbAddrRStoTS is lacking an exit out of the loop when determining tileX and tileY. As a result, tileX and tileY always end up with the maximum value. Since there is no defined way of early exit (no equivalent to the C ""break""), this can be solved by running the loop backward like so: {{{ for( i = num_tile_columns_minus1; i >= 0; i-- ) if( tbX >= colBd[ i ] ) tileX = i }}} Alternatively: {{{ tileX = -1 for( i = 0; i <= num_tile_columns_minus1; i++ ) if( ( tileX < 0 ) && ( tbX >= colBd[ i ] ) ) tileX = i }}} " pieterkapsenberg D8 (J1003) d7 725 typo in BaseSliceAddrRS definition Text D8 (J1003) d7 defect bbross closed 2012-09-06T13:31:15+02:00 2012-09-11T09:21:14+02:00 "In the text BaseSliceAddrRS is defined as follows : === The variable BaseSliceAddrRS is derived as follows. – If dependent_slice_flag is equal to 0, BaseSliceAddrRS is set equal to slice_address. – Otherwise BaseSliceAddrRS is set equal to BaseSliceAddrRS of the preceeding slice containing the coding tree block for which the coding tree block address is ctbAddrTStoRS[ ctbAddrRStoTS[ SliceCtbAddrRS ] − 1 ]. === The second part should be replaced by : Otherwise BaseSliceAddrRS is set equal to BaseSliceAddrRS of the preceeding slice containing the coding tree block for which the coding tree block address is ctbAddrTStoRS[ ctbAddrRStoTS[ '''slice_address''' ] − 1 ]. Indeed SliceCtbAddrRS is not used anymore. " Jing-Jing Chung D8 (J1003) d7 726 Typo in definition of cu_qp_delta_enabled_flag Text D8 (J1003) d7 defect bbross closed 2012-09-06T15:24:38+02:00 2012-09-11T09:21:14+02:00 "According to the definition of cu_qp_delta_enabled_flag, one can derive that diff_cu_qp_delta_depth syntax element is present is always present regardless the value of regardless the value of cu_qp_delta_enabled_flag. My suggsetion to the definition of cu_qp_delta_enabled_flag: cu_qp_delta_enabled_flag equal to 1 specifies that the diff_cu_qp_delta_depth syntax element is present in the picture parameter set and cu_qp_delta is signaled. If cu_qp_delta_enabled_flag equals to 0 specifies then the diff_cu_qp_delta_depth syntax element is not present in the picture parameter set and cu_qp_delta is not transmitted." shevach D8 (J1003) d7 729 7.4.5.4: Unclear LumaWeightLX / ChromaWeightLX range Text D8 (J1003) d7 defect bbross closed 2012-09-11T19:06:22+02:00 2012-09-12T13:57:47+02:00 "Hi, In chapter 8.5.2.2.3.2, weighted predictions is performed according to LumaWeightLX and ChromaWeightLX. In chapter 7.4.5.4 those values are defined by: ""The variable LumaWeightL0[ i ] is specified by (1 << luma_log2_weight_denom ) + delta_luma_weight_l0[ i ]. When luma_weight_l0_flag[ i ] is equal to 1, the value of delta_luma_weight_l0[ i ] shall be in the range of −128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, LumaWeightL0[ i ] is inferred to be equal to 2^luma_log2_weight_denom for RefPicList0[ i ]."" I suspect a typo here. Is the following more accurate ? : ""The variable LumaWeightL0[ i ] is specified by (1 << luma_log2_weight_denom ) + delta_luma_weight_l0[ i ]. When luma_weight_l0_flag[ i ] is equal to 1, the value of '''LumaWeightL0'''[ i ] shall be in the range of −128 to 127, inclusive. When luma_weight_l0_flag[ i ] is equal to 0, LumaWeightL0[ i ] is inferred to be equal to 2^luma_log2_weight_denom for RefPicList0[ i ]."" Same remark for ChromaWeightLX definition. Regards, Alexis " AlexisLefebvre D8 (J1003) d7 730 video_format incorrectly refers to Table E-2 Text D8 (J1003) d7 defect bbross closed 2012-09-11T19:13:04+02:00 2012-09-19T11:08:57+02:00 "In E.2.1, '''video_format''' is specified in Table E-2. But Table E-2 defines '''colour primaries'''. I believe the appropriate table is missing altogether. Referring to the AVC standard, we can see that Table E-2 specifies video_format and Table E-3 specifies colour primaries. Perhaps this was the intent." dthoang D8 (J1003) d7 731 Figure C-2: fields / frames Text D8 (J1003) d7 defect bbross closed 2012-09-12T08:55:46+02:00 2012-11-30T16:00:20+01:00 "Figure C-2 * Compared to Annex C in H.264/AVC, Figure C-2 mentions ""fields or frames"" and ""fields of frames"". Both should probably be changed to ""pictures"". Subclause C.1.1 * Typo: ""... following conditions is true''':''', InitCpbRemovalDelay[...""" mwi D8 (J1003) d7 732 8.7.2.3 Derivation process of boundary filtering strength Text D8 (J1003) d7 defect bbross closed 2012-09-12T13:28:57+02:00 2012-09-12T14:22:46+02:00 "In the paragraph (8.7.2.3 Derivation process of boundary filtering strength) page 148. 1-The sentence : ((If the sample p0 or q0 is in the luma coding block of a coding unit coded with intra prediction mode, the variable bS[ xDi ][ yDj ] is set equal to 2. Otherwise, if the block edge is also a transform block edge and the sample p0 or q0 is in a luma transform block which contains non-zero transform coefficient level----)). The boundary strength (BS) for the last condition is not specified!! 2-The sentence : ((For the prediction of the luma prediction block containing the sample p0 different reference pictures or a different number of motion vectors are '''used than for the''' prediction of the luma prediction block containing the sample q0.)) is not clear!!" azaam D8 (J1003) d7 736 """quantization group"" not defined in 8.6.1" Text D8 (J1003) d7 defect bbross closed 2012-09-13T00:05:37+02:00 2012-10-05T13:55:39+02:00 "Likely meant to be tied to the coded_sub_block_flag construction in 7.4.12 and lastSubBlock in 7.3.13. (discovered by Purvin.Pandit@harmonicinc.com)" chadfogg D8 (J1003) d7 742 8.6.1 : incoherence in quantization group definition Text D8 (J1003) d7 defect bbross closed 2012-09-13T09:46:22+02:00 2012-10-05T13:56:04+02:00 "My understanding of chapter 8.6.1 is that a quantization group is a set of consecutive coding units (CU) in decoding order that have the same qPy_pred. The smallest quantization group size is (1<= 2, (8-20) reads candModeList[2] = 2 + ((candIntraPredModeA - 2 + 1) % 32) so when candIntraPredModeA == 33, this formula gives candModeList[2] = 2 + ((33 - 2 + 1) % 32) = 2 + (32 % 32) = 2 I think that in this case, we should use the mode 34 for candModeList[2] instead of 2 because it is the neighbouring mode of 33. If this suggestion is adopted, the new formula for (8-20) will be : candModeList[2] = 3 + ((candIntraPredModeA - 2) % 32) 2. Also in the same case candIntraPredModeA == candIntraPredModeB and candIntraPredModeA >= 2, + if candIntraPredModeA == 2, candModeList[1] and candModeList[2] are 3 and 33 + if candIntraPredModeA == 34, candModeList[1] and candModeList[2] are 2 and 33 I am wondering in these two cases, instead of choosing the opposite direction (33 and 2 respectively), whether neighbouring modes (4 and 32) will be better. In other words, + if candIntraPredModeA == 2, candModeList[1] and candModeList[2] are 3 and 4 + if candIntraPredModeA == 34, candModeList[1] and candModeList[2] are 32 and 33 Best regards, Phuong Nguyen." PhuongNguyen D8 (J1003) d7 647 Condition on LongTermRefPic missing in spatial mvp derivation Text D8 (J1003) d7 defect bbross closed 2012-07-30T15:15:44+02:00 2012-09-11T09:21:14+02:00 "In ""8.5.2.1.6 Derivation process for motion vector predictor candidates"", The conditions: ""LongTermRefPic( currPic, refIdxLX, RefPicListX) is equal to LongTermRefPic( currPic, RefIdxLX [ xBk ][ yBk ], RefPicListX)"" and ""LongTermRefPic( currPic, refIdxLX, RefPicListX) is equal to LongTermRefPic( currPic, RefIdxLY [ xBk ][ yBk ], RefPicListY)"" are missing. A fix based on JCTVC-J1003_d7 is attached." bbross D8 (J1003) d7 652 8.7.1. General in In-loop filter Text D8 (J1003) d7 defect bbross closed 2012-08-02T08:44:07+02:00 2012-09-11T09:22:09+02:00 """The three in-loop filters"" => ""The two in-loop filters""" djpark0115 D8 (J1003) d7 655 LCU bits limit in Annex A refers to Log2CtbSize instead of Log2CtbSizeY Text D8 (J1003) d7 defect bbross closed 2012-08-03T01:38:06+02:00 2012-09-11T09:22:09+02:00 "There's a type in Annex A: – The number of times read_bits( 1 ) is called in subclauses 9.3.3.2.2 and 9.3.3.2.3 when parsing coding_tree( ) data for any coding tree block shall not be greater than 768 * ( bit_depth_luma_minus8 + 8 ) * ( 1 << ( '''Log2CtbSize''' − 4 ) ) * ( 1 << ( '''Log2CtbSize''' − 4 ) ). Should be '''Log2CtbSizeY'''" pieterkapsenberg D8 (J1003) d7 658 Subclause 7.3.3 profile_tier_level() referenced as profile_and_level() Text D8 (J1003) d7 defect bbross closed 2012-08-06T08:27:16+02:00 2012-09-11T09:22:10+02:00 In subclause 7.3.3, the syntax function profile_tier_level() is specified. In the text, it is referenced as profile_and_level(). mwi D8 (J1003) d7 667 Missing initialization of combIdx in combined bi-predictive candidates Text D8 (J1003) d7 defect bbross closed 2012-08-08T13:15:07+02:00 2012-09-11T09:22:10+02:00 "In 8.5.2.1.3 Derivation process for combined bi-predictive merging candidates, initialization of combIdx to 0 is missing. " djpark0115 D8 (J1003) d7 674 sao_type_idx typo Text D8 (J1003) d7 defect bbross closed 2012-08-14T06:43:39+02:00 2012-09-11T09:31:05+02:00 Table 9-37 on page 176 uses syntax element names sao_type_luma, sao_type_chroma. This is inconsistent with the rest of the document. Should be changed to sao_type_idx_luma, sao_type_idX_chroma respectively. vkolesn D8 (J1003) d7 682 Typos Text D8 (J1003) d7 defect bbross closed 2012-08-21T13:39:53+02:00 2012-09-11T09:31:05+02:00 """when decoding coding unit"" -> ""when decoding a coding unit""" parmitag D8 (J1003) d7 688 Syntax/Semantics: Organization of subclauses, naming Text D8 (J1003) d7 defect bbross closed 2012-08-23T12:24:50+02:00 2012-09-11T09:31:05+02:00 "The subclause structure differs between syntax and semantics. Fix: Add 7.4.7 ""Coding tree unit semantics"", make ""SAO semantics"" 7.4.7.1 Harmonize titles of 7.3.5.4 and 7.4.5.4 to ""Weighted prediction parameters syntax/semantics""" mwi D8 (J1003) d7 690 Annex A: trivial ditorial issues Text D8 (J1003) d7 defect bbross closed 2012-08-23T12:35:54+02:00 2012-11-30T16:00:20+01:00 "Subclause A.4.2: * delete empty constraint i) (set in a tiny font) Table A-3: * Fix level indication in caption: ""4.3"" should be ""4.1""" mwi D8 (J1003) d7 694 Some very trivial issues Text D8 (J1003) d7 defect bbross closed 2012-08-27T12:46:13+02:00 2012-09-11T09:29:48+02:00 "Trivial Subclause 8.1 * Add **""as specified in subclause 10.1"" to ""The sub-bitstream extraction process ** is applied with TargetDecLayerIdSet and HighestTid as inputs and the output assigned to a bitstream referred to as BitstreamToDecode."" Very trivial Subclause 7.4.1.4.4 * ""the coded the coded"" --> ""the coded"" Subclause 7.4.2.2 * After log2_diff_max_min_coding_block_size: Append ""are derived as follows"" to ""The variables Log2CtbSizeY, PicWidthInCtbsY, PicHeightInCtbsY, PicWidthInMinCbsY, PicHeightInMinCbsY, PicSizeInCtbsY, and PicSizeInSamplesY."" Subclause 8.3.2, NOTE 2 * Add space in ""sequenceparameter set"" Extremely trivial Subclause 7.4.1.2 * Double fullstop after ""Any picture that is a trailing picture shall not have nal_unit_type equal to DLP_NUT or TFD_NUT.."" Subclause 7.4.2.3 * Fullstop missing after semantics of sign_data_hiding_flag Subclause 7.4.5.2 * Double fullstop in use_delta_flag semantics Subclause 7.4.6.2 * Double fullstop after ""If cIdx is equal to 0, bitDepth is set equal to BitDepthY.."" " mwi D8 (J1003) d7 697 Typo in 8.5.2.1.2 about setting availableFlagN Text D8 (J1003) d7 defect bbross closed 2012-08-28T02:43:29+02:00 2012-09-11T09:29:49+02:00 "There are duplicate conditions for setting availableFlagN as below. -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 -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 One condition should be changed to: -N is equal to B2 and the prediction units covering luma location (xB1, yB1) and luma location (xN, yN) have the same motion vectors and the same reference indices " tajime D8 (J1003) d7 704 8.5.2.1.3 combIdx is not initialized Text D8 (J1003) d7 enhancement bbross closed 2012-08-30T06:16:31+02:00 2012-08-30T09:22:54+02:00 "combIdx is used but is not initialized beforehand. Suggestion: [[BR]] When numOrigMergeCand is greater than 1 and less than MaxNumMergeCand, the variable numInputMergeCand is set to numMergeCand, '''the variable combIdx is set to 0''', the variable combStop is set to FALSE and the following steps are repeated until combStop is equal to TRUE. " conrad.ho D8 (K0030) v3 768 missing CABAC termination at the end of tile/WPP Text D8 (K0030) v3 defect bbross closed 2012-09-24T09:25:08+02:00 2012-10-21T11:49:10+02:00 "At the end of tile/WPP, byte_alignment() is called, excepft for the end of slice. However, there is no description for CABAC termination in byte_alignment(). Therefore, there is no CABAC termination at the end of tile, if a slice contains multiple tiles." sasai D8 (K0030) v3 741 pic_order_lsb --> pic_order_cnt_lsb Text D8 (K0030) v3 defect bbross closed 2012-09-13T09:26:33+02:00 2012-09-19T11:04:18+02:00 In Note 1 in subclause 8.3.1, pic_order_lsb should be pic_order_cnt_lsb mwi D8 (K0030) v3 745 edgeIdx=4 for SaoTypeIdx=2 Text D8 (K0030) v3 defect bbross closed 2012-09-15T00:39:10+02:00 2012-09-17T11:46:37+02:00 "In equation (8-322), edgeIdx=4 if recPicture[ xC + i ][ yC + j ] > recPicture[ xC + i + hPos[ 0 ] ][ yC + j + vPos[ 0 ] ] && recPicture[ xC + i ][ yC + j ] > recPicture[ xC + i + hPos[ 1 ] ][ yC + j + vPos[ 1 ] ] edgeIdx should be in the [0, 3] range. " sorin D8 (K0030) v3 759 Text clarification for binarization of cu_qp_delta_abs Text D8 (K0030) v3 defect bbross closed 2012-09-21T01:03:39+02:00 2012-09-24T12:58:55+02:00 "In Table 9-32, cu_qp_delta_abs is defined to have a prefix and a suffix. However, cu_qp_delta_abs only has a suffix when the value is > 4. This is not clear from current text. Suggest describing binarization in a separate clause: 9.3.2.x Binarization process for cu_qp_delta_abs Input to this process is a request for a binarization for the syntax element cu_qp_delta_abs. Output of this process is the binarization of the syntax element. The binarization of the syntax element cu_qp_delta_abs consists of a prefix part and (when present) a suffix part. The prefix of the binarization is specified by invoking the TU binarization process for the prefix part of the value specified by Min (5, synVal) with cMax = 5. When prefix is greater than 4, the suffix bin string is derived using the EGk binarization as specified in subclause 9.3.2.4 for the suffix part ( cu_qp_delta_abs − 4 ) with the Exp-Golomb order k set equal to 0. " vsze D8 (K0030) v3 762 default value for ScalingList Text D8 (K0030) v3 defect bbross closed 2012-09-22T05:18:15+02:00 2012-10-04T15:24:02+02:00 "It is not clear which value should be set into ScalingList in the case that ""scaling_list_enable_flag =1"", ""sps_scaling_list_data_present_flag = 0"" and ""pps_scaling_list_data_present_flag = 0""." sasai D8 (K0030) v3 763 "default value for ""split_cu_flag""" Text D8 (K0030) v3 defect bbross closed 2012-09-22T05:21:47+02:00 2012-10-21T11:57:53+02:00 """split_cu_flag"" is used without definition in case of ""NumPCMBlock!=0""." sasai D8 (K0030) v3 764 misplaced parenthesis in cRiceParam Eq. (9-7) Text D8 (K0030) v3 defect bbross closed 2012-09-24T07:39:35+02:00 2012-09-24T14:17:58+02:00 "Section 9.3.2.7: cRiceParam = Min( cLastRiceParam + ( cLastAbsLevel > ( 3 * ( 1 << cLastRiceParam ) ) ) ? 1 : 0, 4 ) (9 7) should be: cRiceParam = Min( cLastRiceParam + ( cLastAbsLevel > ( 3 * ( 1 << cLastRiceParam ) ) ? 1 : 0 ), 4 ) (9 7) or: cRiceParam = Min( cLastRiceParam + ( cLastAbsLevel > 3 * ( 1 << cLastRiceParam ) ? 1 : 0 ), 4 ) (9 7) " sorin D8 (K0030) v3 765 "Unneeded ""not"" in section 9.3.2.7" Text D8 (K0030) v3 defect bbross closed 2012-09-24T07:45:20+02:00 2012-09-24T13:36:31+02:00 "Remove ""not"" from the last paragraph in section 9.3.2.7: ""When the prefix bin string is not equal to the bit string ..."" should be: ""When the prefix bin string is equal to the bit string ..."" " sorin D8 (K0030) v3 766 clarification of NumPCMBlock Text D8 (K0030) v3 defect bbross closed 2012-09-24T09:06:06+02:00 2012-09-25T13:06:18+02:00 """NumPCMBlock=0"" in coding_tree_unit() is not necessary since NumPCMBlock is decremented in pcm_sample()." sasai D8 (K0030) v3 767 unnecessary condition for cbf_cb/cbf_cr in 7.3.8.8 Text D8 (K0030) v3 defect bbross closed 2012-09-24T09:11:12+02:00 2012-09-24T14:02:22+02:00 "At 7.3.8.8 Transform tree syntax, the condition for cbf_cb / cbf_cr, the condition "" if ( trafoDepth == 0 | | log2TrafoSize > 2 ) "" is present. However, if trafoDepth is equal to ""0"", log2TrafoSize is always greater than and equal to ""3"". Replace if( trafoDepth == 0 | | log2TrafoSize > 2 ){ if( trafoDepth == 0 | | cbf_cb[ xBase ][ yBase ][ trafoDepth - 1 ] ) cbf_cb[ x0 ][ y0 ][ trafoDepth ] if( trafoDepth == 0 | | cbf_cr[ xBase ][ yBase ][ trafoDepth - 1 ] ) cbf_cr[ x0 ][ y0 ][ trafoDepth ] } by if( log2TrafoSize > 2 ) { if( trafoDepth == 0 | | cbf_cb[ xBase ][ yBase ][ trafoDepth - 1 ] ) cbf_cb[ x0 ][ y0 ][ trafoDepth ] if( trafoDepth == 0 | | cbf_cr[ xBase ][ yBase ][ trafoDepth - 1 ] ) cbf_cr[ x0 ][ y0 ][ trafoDepth ] } " sasai D8 (K0030) v3 769 typos in Table 9-4 and section 9.3.3.1.5. Text D8 (K0030) v3 defect bbross closed 2012-09-24T21:03:09+02:00 2012-09-25T13:10:30+02:00 "In Table 9-4, init range of last_significant_coeff_x_prefix and last_significant_coeff_y_prefix for initType=2 should be 36..53 instead of 36..54 (to be consistent with Table 9-26 and 9-27) In section 9.3.3.1.5., ""coeff_abs_greater1_flag"" should be ""coeff_abs_level_greater1_flag""" vsze D8 (K0030) v3 770 mismatch between WD and HM for context idx for 3rd bin of part_mode Text D8 (K0030) v3 defect bbross closed 2012-09-24T23:41:50+02:00 2012-09-25T16:13:08+02:00 "In HM-8.0, two different contexts are used for the binIdx=2 of part_mode: m_cCUPartSizeSCModel.get( 0, 0, 2) when (cLog2CbSize = = Log2MinCbSizeY)&& (cLog2CbSize > 3). or m_cCUAMPSCModel.get( 0, 0, 0 )) when (cLog2CbSize > Log2MinCbSizeY) && (amp_enable_flag) In WD, same context is used for binIdx=2 of part_mode in both cases (Table 9-37) Suggested correction: Table 9-4 increase context range for part_mode to 0, 1..4, 5..8 Table 9-12 add missing contexts Table 9-37 make ctxIdxInc of binIdx=2 of part_mode be 3 or 4 depending on (cLog2CbSize = = Log2MinCbSizeY)?" vsze D8 (K0030) v3 773 8.7.2.4.8 wrong chroma location index for pcm_flag Text D8 (K0030) v3 defect bbross closed 2012-09-25T11:49:05+02:00 2012-09-25T12:57:53+02:00 "the input of 8.7.2.4.8 are locations of p0 and q0, ( xP0, yP0 ) and ( xQ0, yQ0 ), which are chroma coordination so when pcm_flag is used, it should be pcm_flag[ 2*xP0 ][ 2*yP0 ] instead of pcm_flag[ xP0 ][ yP0 ] " jeromnhsu D8 (K0030) v3 774 8.7.2.4.5 typo Text D8 (K0030) v3 defect bbross closed 2012-09-25T11:55:53+02:00 2012-09-25T12:40:12+02:00 "8.7.2.4.5 is for Filtering process for chroma block edges inputs ( xC, yC ) and ( xB, yB ) should be chroma locations as follows, – a chroma location ( xC, yC ) specifying the top-left sample of the current chroma coding block relative to the top-left chroma sample of the current picture, – a chroma location ( xB, yB ) specifying the top-left sample of the current chroma block relative to the top left sample of the current chroma coding block," jeromnhsu D8 (K0030) v3 775 wrong subclause reference Text D8 (K0030) v3 defect bbross closed 2012-09-25T11:59:23+02:00 2012-09-25T12:36:01+02:00 "in 8.7.2.4.1 and 8.7.2.4.2 reference to subclause 0 should be changed to subclause 8.7.2.4.4 " jeromnhsu D8 (K0030) v3 777 Clarification of PCM coding size Text D8 (K0030) v3 defect bbross closed 2012-09-26T04:36:07+02:00 2012-10-21T11:55:00+02:00 "When both Log2MinCbSizeY and Log2CtbSizeY are equal to 6, PCM coding can not be used since the variable Log2MaxIpcmCbSizeY has to be equal or less than 5. In this case, PCM coding can not be used to avoid the bit constraint at LCU level." sasai D8 (K0030) v3 786 derivation of default 4x4 scaling_lists in SPS undefined when transform skipping is enabled Text D8 (K0030) v3 defect bbross closed 2012-09-29T00:34:38+02:00 2012-10-21T11:56:25+02:00 "In the text, section 7.4.2.4 says: If transform_skip_enabled_flag is equal to 1 and SizeID is equal to 0, ScalingList[ SizeID ][ MatrixID ][ i ] is set equal to 16 for i=0..15 Otherwise, ScalingList[ SizeID ][ MatrixID ] is specified in Table 7 4 and Table 7.5. scaling_list_data() is called from SPS as well as PPS. Default 4x4 scaling lists are undefined in SPS because transform_skip_enabled_flag is unkown in SPS. Therefore, when scaling lists are not carried in PPS but transform skipping is enabled, the spec is broken as 4x4 default scaling lists inherited from SPS are undefined. HM8.0 encoder/decoder mismatches for the following setting when transform skipping is enabled SPS: • scaling_list_enable_flag = 1 • sps_scaling_list_data_presetnt_flag = 1 • In scaling_list_data(), intra luma 4x4 scaling list is signalled as a default list (scaling_list_pred_mode_flag = 0 and scaling_list_pred_matrix_id_delta = 0). PPS : • transform_skip_enabled_flag = 1 • pps_scaling_list_data_present_flag = 0 the encoder uses the flat default list, while the decoder uses the non-flat default, so we have encoder-decoder mismatch here. Potential solution: 1) to insert another flag (say sps_flat_scaling_list_enabled_flag) in SPS to specifiy whether flat 4x4 default scaling lists are carried in SPS when scaling_list_data() is called from SPS. 2) semantics of sps_flat_scaling_list_enabled_flag sps_flat_scaling_list_enabled_flag equal to 1 specifies that ScalingList[0][ MatrixID ][ i ] is set equal to 16 for MatrixID = 0..5 and i = 0..15 when both scaling_list_pred_mode_flag and scaling_list_pred_matrix_id_delta are set equal to 0. When not present, the value of sps_flat_scaling_list_enabled_flag is inferred to be equal to 0. 3) modify section 7.4.5 as If sps_flat_scaling_list_enabled_flag is equal to 1, or transform_skip_enabled_flag is equal to 1 and SizeID is equal to 0, ScalingList[ SizeID ][ MatrixID ][ i ] is set equal to 16 for i=0..15 – Otherwise, ScalingList[ SizeID ][ MatrixID ] is specified in Table 7 4 and Table 7.5 Suggest to have more discussion on this topic at the upcoming HEVC meeting. " zhou D8 (K0030) v3 787 Scaling lists undefined when scaling_list_enable_flag = 1 and sps_scaling_list_data_presetnt_flag = 0 Text D8 (K0030) v3 defect bbross closed 2012-09-29T01:34:24+02:00 2012-10-04T14:56:15+02:00 "spec says sps_scaling_list_data_present_flag equal to 1 specifies that scaling list data are present in the sequence parameter set. sps_scaling_list_data_present_flag equal to 0 specifies that scaling list data are not present in the sequence parameter set. When not present, the value of sps_scaling_list_data_present_flag is inferred to be 0. when scaling_list_enable_flag = 1 and sps_scaling_list_data_presetnt_flag = 0 the actual scaling lists in SPS are undefined. recommend to specify that scaling lists in SPS are inferred to default scaling lists when scaling_list_enable_flag = 1 and sps_scaling_list_data_presetnt_flag = 0" zhou D8 (K0030) v3 752 "Typo: 7.3.5 ""scaling_list_data"", 7.4.5 ""scaling_list_delta_coef""" Text D8 (K0030) v3 defect bbross closed 2012-09-18T04:48:34+02:00 2012-09-19T11:04:37+02:00 "In 7.3.5, ""u(1)"" for the line ""nextCoef = 8"" should be removed. In 7.4.5, equation 7-34, ""ScalingFactor[ 2 ][ matrixId ][ 0 ][ 0 ][ 0 ]"" should be ""ScalingFactor[ 2 ][ matrixId ][ 0 ][ 0 ]""." conrad.ho D8 (K0030) v3 778 Subclause 7.4.3: general_tier_flag Text D8 (K0030) v3 enhancement bbross closed 2012-09-27T10:38:40+02:00 2012-09-28T11:54:50+02:00 In Subclause 7.4.3, `general_tier_flag` should be bold in its semantics specification. mwi D8 (K0030) v4 802 7.3.8.10 incorrect log2TrafoSize passed for chroma transform Text D8 (K0030) v4 defect bbross closed 2012-10-18T12:39:10+02:00 2012-11-30T14:31:10+01:00 "In 7.3.8.10 Transform unit syntax: If log2TrafoSize > 2, when residual_coding() is invoked for cb and cr, the 'log2TrafoSize' argument is set to same size as for luma). For 4:2:0, this would result in the chroma transform being the same size as the luma transform. Instead: If log2TrafoSize > 2, residual_coding() should be invoked with 'log2TrafoSize - 1', as the chroma transform size should be half the luma transform size for 4:2:0 when luma transform size is > 4x4. " crosewarne D8 (K0030) v4 796 "Suggested solution for ""intra PCM mode"" definition" Text D8 (K0030) v4 task bbross closed 2012-10-14T04:23:25+02:00 2012-10-21T11:49:58+02:00 "In the current text, there is an editor note ""Define ""intra PCM mode"" somewhere."" The following two solutions are suggested: Solution1: Specify the meaning of pcm_flag=1 by using other words instead of “intra PCM mode.” Solution2: Define ""intra PCM mode."" Attachment describes editorial changes for both solutions. " kchono D9 (K1003) v10 687 Missing clip in 8.6.5 Picture construction process prior to in-loop filter process? Text D9 (K1003) v10 defect bbross closed 2012-08-22T12:47:05+02:00 2012-12-07T12:13:47+01:00 "In section 8.6.5 on ""Picture construction process prior to in-loop filter process"", either Inter or Intra predicted samples are added to residual samples to form reconstructed samples. This process does not clip the reconstructed samples to be in the range 0 to (1<> Log2CtbSizeY ) is equal to ( yPRb >> Log2CtbSizeY )"" to know whether to select central luma location or bottom-right luma location. This force to work always with the same Ctb row in the collocated picture and in the current picture. But it is not explained what to do when the collocated Pb cross the right picture boundary. For example the top-right Pb of the current Ctb can have its collocated Pb outside the picture boundary if the current Ctb is the last Ctb of a picture row and it respect the ""( yP >> Log2CtbSizeY ) is equal to ( yPRb >> Log2CtbSizeY )"" equation. In this case I see 2 solutions : 1) Central luma location is used instead. 2) The collocated Pb is marked as unavailable. Regards, Alexis (Pb: prediction block, Ctb: coding tree block ) " AlexisLefebvre D9 (K1003) v10 757 8.5.3.1.7 unvalued refIdxCol and listCol used Text D9 (K1003) v10 defect bbross closed 2012-09-20T06:24:51+02:00 2012-12-07T12:14:29+01:00 "The spec said: ""The variables mvLXCol and availableFlagLXCol are derived as follows. – If one or more of the following conditions are true, both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0. –colPb is coded in an intra prediction mode. -colPb is marked as ""unavailable"". –slice_temporal_mvp_enable_flag is equal to 0. –LongTermRefPic( currPic, refIdxLX, ListX ) is not equal to LongTermRefPic( colPic, refIdxCol, listCol ). – Otherwise, the motion vector mvCol, the reference index refIdxCol, and the reference list identifier listCol are derived as follows. ..."" However, for the 4th condition, the values of refIdxCol and listCol are specified in ""otherwise"" part; thus LongTermRefPic(colPic, refIdxCol, listCol) is vague." conrad.ho D9 (K1003) v10 771 Clarify about formula of RefPicOrderCnt and LongTermRefPic Text D9 (K1003) v10 defect bbross closed 2012-09-25T03:51:44+02:00 2012-12-07T12:15:18+01:00 "In subclause 8.5.3.1.7 of JCTVC-K0030_V3 (page 125), there's confusion about the formula for RefPicOrderCnt. We can update it as follows to make it more clear. The original version: The function RefPicOrderCnt( picX, refIdx, LX ) returns the picture order count PicOrderCntVal of the reference picture with index refIdx from reference picture list LX of the picture picX and is specified as follows. RefPicOrderCnt( picX, refIdx, LX ) = PicOrderCnt(RefPicListX[refIdx] of the picture picX) (8 141) The possible updated version: The function RefPicOrderCnt( picX, pbX, refIdx, LX ) returns the picture order count PicOrderCntVal of the reference picture with index refIdx from reference picture list LX of the slice containing prediction block pbX in the picture picX and is specified as follows. RefPicOrderCnt( picX, pbX, refIdx, LX ) = PicOrderCnt(RefPicListX[refIdx] of the prediction block pbX in the picture picX) (8-151) The similar update for subclause8.5.3.1 (page 114) The original version: The function LongTermRefPic( picX, 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 picture picX was marked as ""used for long term reference"" at the time when picX was the current picture, LongTermRefPic( picX, refIdx, LX ) is equal to 1; otherwise LongTermRefPic( picX, refIdx, LX ) is equal to 0. The possible updated version: The function LongTermRefPic( picX, pbX, 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 pbX in the picture picX was marked as ""used for long term reference"" at the time when picX was the current picture, LongTermRefPic( picX, pbX, refIdx, LX ) is equal to 1; otherwise LongTermRefPic( picX, pbX, refIdx, LX ) is equal to 0. Thanks a lot to Benjamin's kinldy help on the clarification for such confusion points. Best regards. Viking " vikingwang@… D9 (K1003) v10 868 "Incorrect cross reference in Table 9 37 ""Assignment of ctxIdxInc to syntax elements with context coded bins""" Text D9 (K1003) v10 defect bbross closed 2012-11-29T14:35:41+01:00 2012-12-07T12:15:46+01:00 "If I want to know '''ctxIdxInc''' for '''last_significant_coeff_x_prefix''' or '''last_significant_coeff_y_prefix''', I am directed to subclause ''9.2.1.2 Memorization process for context variables''. The correct subclause for the crossreference is ''9.2.3.1.2 Derivation process of ctxIdxInc for the syntax elements last_significant_coeff_x_prefix and last_significant_coeff_y_prefix'' " Parabola D9 (K1003) v10 873 ctDepth[ xL ][ yL ] is used in Table 9-38 although not defined as global array Text D9 (K1003) v10 defect bbross closed 2012-11-30T16:58:05+01:00 2012-12-07T12:16:12+01:00 Gerhard D9 (K1003) v10 876 editorial: description of cIdx and typo in 7.3.9.5 Text D9 (K1003) v10 defect bbross closed 2012-12-01T21:04:42+01:00 2012-12-07T12:16:30+01:00 "* '''Inconsistency:''' In semantics, cIdx is described as colour component. Several places under session 8.4.4 onward specified cIdx as chroma component where it can be either luma or chroma. * '''Typo:''' Missing comma in session 7.3.9.5. transform_tree( x0, y0 x0, y0, log2CbSize, 0, 0 ) should be transform_tree( x0, y0''',''' x0, y0, log2CbSize, 0, 0 )" sue.naing D9 (K1003) v10 880 Clumsy syntax for vps_sub_layer_ordering_info_present_flag Text D9 (K1003) v10 enhancement bbross closed 2012-12-02T09:49:08+01:00 2012-12-02T12:18:23+01:00 "There is a loop in the VPS syntax that opens thusly: {{{#!C for( i = ( vps_sub_layer_ordering_info_present_flag ? 0 : vps_max_sub_layers_minus1 ); i <= vps_max_sub_layers_minus1; i++ ) { }}} This takes longer to understand that it should because it does not use idiomatic C-style constructs. It looks ""hackish"". To improve clarity suggest changing to: {{{#!C for( i = 0; vps_sub_layer_ordering_info_present_flag && i <= vps_max_sub_layers_minus1; i++ ) { }}} or {{{#!C if (vps_sub_layer_ordering_info_present_flag) for( i = 0; i <= vps_max_sub_layers_minus1; i++ ) { }}} " Parabola D9 (K1003) v11 686 Difference between uiQtRootCbf and no_residual_syntax_flag Text D9 (K1003) v11 defect bbross closed 2012-08-22T08:59:32+02:00 2013-01-14T15:37:20+01:00 "uiQtRootCbf in HM-8.0 is used as opposite meaning of no_residual_syntax_flag in the WD. Subclause 7.3.9.1 in the WD, the following appears: {{{ if(PredMode[x0][y0]!=MODE_INTRA && !(PartMode==PART_2Nx2N　&& merge_flag[x0][y0])) no_residual_syntax_flag if(!no_residual_syntax_flag) { MaxTrafoDepth=(PredMode[x0][y0]==MODE_INTRA ? max_transform_hierarchy_depth_intra + IntraSplitFlag : max_transform_hierarchy_depth_inter) transform_tree( x0, y0 x0, y0, log2CbSize, 0, 0 ) } }}} In HM-8.0 TDecEntropy::decodeCoeff(), line 573: {{{ UInt uiQtRootCbf = 1; if( !( pcCU->getPartitionSize(uiAbsPartIdx)==SIZE_2Nx2N && pcCU->getMergeFlag( uiAbsPartIdx ) ) ) { m_pcEntropyDecoderIf->parseQtRootCbf(pcCU,uiAbsPartIdx,uiDepth,uiQtRootCbf ); } if(!uiQtRootCbf) { pcCU->setCbfSubParts(0,0,0,uiAbsPartIdx,uiDepth); pcCU->setTrIdxSubParts(0,uiAbsPartIdx,uiDepth); #if !REMOVE_NSQT pcCU->setNSQTIdxSubParts(uiAbsPartIdx,uiDepth); #endif return; } } xDecodeTransform(pcCU,uiLumaOffset,uiChromaOffset,uiAbsPartIdx, uiAbsPartIdx,uiDepth,uiWidth,uiHeight,0,0,bCodeDQP); }}} " tajime D9 (K1003) v11 805 Unused refIdxA in spatial motion vector predictor candidates module Text D9 (K1003) v11 defect bbross closed 2012-10-22T13:29:40+02:00 2013-01-16T17:09:45+01:00 "In, 8.5.3.1.6 Derivation process for motion vector predictor candidates The equation 8-131 is not useful, since refIdxA is not going to be used for scaling. mvLXA = MvLX[ xAk ][ yAk ] (8 130) refIdxA = RefIdxLX[ xAk ][ yAk ] (8 131) " naveensr89 D9 (K1003) v11 831 spatial MVP scaling for mvLXA in AMVP list derivation does not match HM software Text D9 (K1003) v11 defect bbross closed 2012-11-07T23:10:07+01:00 2013-01-14T16:57:47+01:00 "in 8.5.3.1.6 derivation process for motion vector predictor candiadtes For spatial MVP scaling of mvLXA, missing condtional check that the MVP scaling process is not invoked when delta POCs are same. suggested change: in item 7 Replace – When availableFlagLXA is equal to 1, and both refPicListA[ refIdxA ] and RefPicListX[ refIdxLX ] are short-term reference pictures, mvLXA is derived as specified below. with – When availableFlagLXA is equal to 1 and PicOrderCnt( refPicListA[ refIdxA ] ) is not equal to PicOrderCnt( RefPicListX[ refIdxLX ] ) and both refPicListA[ refIdxA ] and RefPicListX[ refIdxLX ] are short-term reference pictures, mvLXA is derived as specified below." zhou D9 (K1003) v11 882 deblocking of 4x4 chroma CBs speficied incorrectly Text D9 (K1003) v11 defect bbross closed 2012-12-02T10:16:21+01:00 2013-01-17T14:55:10+01:00 "In HM-9.0, if the top-left corner of a chroma coding block of size 4x4 is aligned to a chroma location that is not a multiple of 8 in horizontal or vertical direction, the deblocking filter process is not applied to its left or top edge, respectively. If that is the intended behavior, the text has to be modified. One possible solution would be to change: In 8.7.2.4.1 Vertical edge filtering process: – When bS[ xDk*2 ][ yDm*2 ] is greater than 1 and (( xDk >> 3 ) << 3) is equal to xDk, the following ordered steps apply. to – When bS[ xDk*2 ][ yDm*2 ] is greater than 1 and (( ( xC / 2 + xDk ) >> 3 ) << 3) is equal to xC / 2 + xDk, the following ordered steps apply. and in 8.7.2.4.2 Horizontal edge filtering process: – When bS[ xDk*2 ][ yDm*2 ] is greater than 1 and (( yDm >> 3 ) << 3) is equal to yDm, the following ordered steps apply. to – When bS[ xDk*2 ][ yDm*2 ] is greater than 1 and (( ( yC / 2 + yDm ) >> 3 ) << 3) is equal to yC / 2 + yDm, the following ordered steps apply." stefane D9 (K1003) v11 893 PicWidthInSamplesL variable not defined Text D9 (K1003) v11 defect bbross closed 2012-12-07T23:41:13+01:00 2012-12-16T22:39:18+01:00 "8.5.3.2.1 Reference picture selection process refers to (PicWidthInSamplesL)x(PicHeightInSamplesL) but those variables are never defined. Same for (PicWidthInSamplesC)x(PicHeightInSamplesC) The same problem was reported in #443, which has been closed, even though this issue was not resolved. A lot of similar variables are defined in 7-13 through 7-23. " jillboyce D9 (K1003) v11 897 Typo in rowHeight[] derivation Text D9 (K1003) v11 defect bbross closed 2012-12-09T22:58:03+01:00 2012-12-16T22:39:33+01:00 "In section ""6.5.1 Coding tree block raster and tile scanning conversion process"", this line of the pseudocode is incorrect: rowHeight[ num_tile_rows_minus1 ] −= rowHeight[ i ] It should read rowHeight[ num_tile_rows_minus1 ] −= rowHeight[ j ]" Parabola D9 (K1003) v11 898 CtbAddrTS and CtbAddrRS Text D9 (K1003) v11 defect bbross closed 2012-12-10T09:36:47+01:00 2012-12-16T22:39:50+01:00 "Some references to these variables still exist in v11. For example in syntax table for coding_tree_unit(). We understand the intention was to rename them to CtbAddrInTS and CtbAddrInRS respectively. " Parabola D9 (K1003) v11 900 HM/WD mismatch when parsing sao_merge_left/up in dependent slices Text D9 (K1003) v11 defect bbross closed 2012-12-11T12:16:54+01:00 2013-01-16T17:56:02+01:00 "In SAO syntax : ""7.3.9.3 Sample adaptive offset syntax"" The sao_merge_left and sao_merge_up flag are decoded depending on the following conditions : CtbAddrInSliceSeg = CtbAddrInRS − slice_segment_address (...) leftCtbInSliceSeg = CtbAddrInSliceSeg > 0 (...) upCtbInSliceSeg = ( CtbAddrInRS − PicWidthInCtbsY ) >= slice_segment_address The Syntax Element slice_segment_address refers to the current slice segment, which may be dependent OR independent. On the contrary, in HM software, this is applied only to independant slice segments, and sao_merge_up/left flags are allowed on dependent slice boundaries. In the previous quoted text, I suggest to replace the variable ""slice_segment_address"" by ""SliceAddrRS"" " rbertin D9 (K1003) v11 906 Mismatch in location of enable_temporal_mvp_flag Text D9 (K1003) v11 defect bbross closed 2012-12-12T12:32:56+01:00 2013-01-14T17:27:55+01:00 "In 7.3.8.1 ""General slice segment header syntax"", the text has slice_temporal_mvp_enable_flag appearing just before slice_sao_luma_flag, but the reference code 9.1rc1 has it appearing afterwards. if( sps_temporal_mvp_enable_flag ) slice_temporal_mvp_enable_flag } if( sample_adaptive_offset_enabled_flag ) { slice_sao_luma_flag slice_sao_chroma_flag } Line 1054 of TDecCAVLC.cpp: READ_FLAG(uiCode, ""slice_sao_luma_flag""); rpcSlice->setSaoEnabledFlag((Bool)uiCode); Line 1069: READ_FLAG( uiCode, ""enable_temporal_mvp_flag"" ); " peterderivaz D9 (K1003) v11 910 8.5.3.1.8 Wrong operand direction when using DiffPicOrderCnt() Text D9 (K1003) v11 defect bbross closed 2012-12-14T12:51:12+01:00 2013-01-14T17:41:10+01:00 " In the prior K1003 v10 spec, it said [[BR]] ""If PicOrderCnt( pic ) of every picture pic in every reference picture list of the current slice is less than or equal to PicOrderCntVal, mvCol, refIdxCol, and listCol are set equal to..."" Based on it, the text using DiffPicOrderCnt() should be DiffPicOrderCnt( pic, currPic ) not DiffPicOrderCnt( currPic, pic ). Is this a typo in v11?" conrad.ho D9 (K1003) v11 911 AMVP process might overwrite candidate A Text D9 (K1003) v11 defect bbross closed 2012-12-14T18:20:32+01:00 2012-12-14T18:43:48+01:00 "In 8.5.3.1.6 - Derivation process for motion vector predictor candidates, step 4 of the derivation of motion vector mvLXB and the availability flag availableFlagLXB reads as follows: 4. When isScaledFlagLX is equal to 0 and availableFlagLXB is equal to 1, availableFlagLXA is set equal to 1 and the following assignments are made.[[BR]]mvLXA = mvLXB[[BR]]refIdxA = refIdxLXB Shouldn't this step be conditional on availableFlagLXA being 0 initially? Otherwise possibly the already-added A candidate will get overwritten. The code in HM-9 does not appear to allow replacing an added candidate. " pieterkapsenberg D9 (K1003) v11 912 CABAC context initialization at start of tile and dependent slice segment. Text D9 (K1003) v11 defect bbross closed 2012-12-14T20:34:39+01:00 2013-01-14T17:31:08+01:00 "If the current coding tree block is the first coding tree block in a tile and also the first coding tree block in a dependent slice segment (see example in Figure 6-5), the Initialization Process in Section 9.2.1 will fail to reinitialize the arithmetic decoding context. Instead, the state will be copied from the end of the previous tile, creating a cross-tile decoding dependency. There should be an additional case here to check for the start of a tile. Something like the following: {{{ #!div style=""font-size: 80%"" The context variables of the arithmetic decoding engine are initialized as follows. * If the current coding tree block is the first coding tree block in a tile, the initialization process for context variables is invoked as specified in subclause 9.2.1.1. * Otherwise, if entropy_coding_sync_enabled_flag is equal to 1, ... }}} The HM-9.1 software has the same issue. A separate ticket will be filed for the software bug." bheng D9 (K1003) v11 899 Some indices of TransCoeffLevel are missing Text D9 (K1003) v11 defect bbross closed 2012-12-11T04:50:22+01:00 2012-12-16T22:40:08+01:00 "In ""8.6.3 Scaling process for transform coefficients"", Some indices of TransCoeffLevel are missing. Specifically, d[ x ][ y ] = Clip3( −32768, 32767, ( ( TransCoeffLevel[ xT ][ yT ][ cIdx ] * m[ x ][ y ] * ... (8 263) should be replaced with d[ x ][ y ] = Clip3( −32768, 32767, ( ( TransCoeffLevel[ xT ][ yT ][ cIdx ][ x ][ y ] * m[ x ][ y ] * ... (8 263)" Tomohiro Ikai D9 (K1003) v11 902 Mismatched { } in rowHeight derivation Text D9 (K1003) v11 defect bbross closed 2012-12-12T10:32:07+01:00 2012-12-16T22:40:24+01:00 "In section ""6.5.1 Coding tree block raster and tile scanning conversion process"", the code deriving rowHeight has one { and two }. I believe the line: for( j = 0; j < num_tile_rows_minus1; j++ ) should change to for( j = 0; j < num_tile_rows_minus1; j++ ) {" peterderivaz D9 (K1003) v11 907 Incorrect cMax for last_significant_coeff_x_suffix and last_significant_coeff_y_suffix Text D9 (K1003) v11 defect bbross closed 2012-12-12T12:37:08+01:00 2013-01-17T14:55:37+01:00 "Table 9-32 says that last_significant_coeff_x_suffix uses a binarization of ""FL, cMax =(last_significant_coeff_x_prefix >> 1) − 1"". However, on page 92 is says: ""The values of last_significant_coeff_x_suffix shall be in the range from 0 to ( 1 << ( ( last_significant_coeff_x_prefix >> 1 ) − 1 ) ) − 1, inclusive."" I believe this means that the binarization used is actually: ""FL, cMax = ( 1 << ( ( last_significant_coeff_x_prefix >> 1 ) − 1 ) )"". " peterderivaz D9 (K1003) v11 908 "Missing input of cIdx in ""Transformation process for scaled transform coefficients""" Text D9 (K1003) v11 defect bbross closed 2012-12-12T12:40:41+01:00 2012-12-16T22:40:47+01:00 "Process 8.6.4 ""Transformation process for scaled transform coefficients"" uses cIdx but this is not an input to the process." peterderivaz D9 (K1003) v11 909 Confusion in whether coordinates are for luma or chroma samples Text D9 (K1003) v11 defect bbross closed 2012-12-12T12:56:36+01:00 2013-01-17T14:56:01+01:00 "There seems to be a general confusion as to whether sample locations for blocks with cIdx>0 is given in luma or chroma samples. The syntax elements seem to consistently use locations in luma samples, but the semantics are less clear. For example, in 8.4.4.1 ""General decoding process for intra blocks"", split_transform_flag is accessed via split_transform_flag[ xB0 << 1 ][ yB0 << 1 ][ trafoDepth ], implying locations in chroma samples. however, in 8.4.4.2.1 ""General intra sample prediction"", equations 8-26 and 8-27 compute what is called ""the luma location"" (based on the same xB0 values), and use PredMode[xBN][yBN], implying locations in luma samples " peterderivaz D9 (K1003) v11 905 Confusion in scan order specification based on IntraPredMode Text D9 (K1003) v11 enhancement bbross closed 2012-12-12T11:35:17+01:00 2012-12-16T22:41:02+01:00 "7.4.9.11 ""Residual coding semantics"" specifies the scan order in terms of a variable IntraPredMode. However, it is not clear what is meant by IntraPredMode. This name appears in the document as: 1. a parameter intraPredMode for some processes 2. an array IntraPredMode for luma prediction mode 3. a variable IntraPredModeC for chroma prediction mode Perhaps it should be clarified which (if any) is the correct interpretation?" peterderivaz D9 (K1003) v12 917 Incorrect invocation of transform block boundary in deblocking Text D9 (K1003) v12 defect bbross closed 2012-12-17T10:50:47+01:00 2012-12-28T19:06:23+01:00 "In 8.7.2 ""Deblocking filter process"" there are two invocations of transform block boundary on page 150. In both cases, the text says ""with the luma location (xB,yB) set equal to (0,0)"". I believe that both of these should instead say ""with the luma location (xB,yB) set equal to (xC,yC)"". " peterderivaz D9 (K1003) v12 915 Missing equation number in deblocking Text D9 (K1003) v12 defect bbross closed 2012-12-17T10:34:43+01:00 2012-12-28T19:06:53+01:00 "In 8.7.2.4.3 ""Decision process for luma block edges"" there is a missing equation number between 8-281 and 8-282 for variable dp0." peterderivaz D9 (K1003) v12 916 Inconsistent capitalisation of Log2MinCuQ[P/p]DeltaSize Text D9 (K1003) v12 defect bbross closed 2012-12-17T10:38:28+01:00 2012-12-28T19:07:13+01:00 "Log2MinCuQPDeltaSize appears 3 times (with an uppercase P) Log2MinCuQpDeltaSize appears 3 times (with a lowercase p) I believe the lowercase p is more consistent with the rest of the text (such as QpBdOffset)" peterderivaz D9 (K1003) v12 918 Typo in input for 8.5.4.1 Decoding process for luma residual blocks Text D9 (K1003) v12 defect bbross closed 2012-12-17T12:37:21+01:00 2012-12-28T19:07:43+01:00 "In 8.5.4.1 ""Decoding process for luma residual blocks"" the text reads: ""a variable log2Size specifying the size of the current luma block,"" I believe this variable should be called log2TrafoSize instead of log2Size." peterderivaz D9 (K1003) v12 921 Superfluous semicolon in 7-64 Text D9 (K1003) v12 defect bbross closed 2012-12-18T17:14:05+01:00 2013-01-14T17:36:24+01:00 "In 7.4.8.3 ""Reference picture list modification semantics"" for list_entry_l0[i] the equation 7-64 includes: NumPocTotalCurr = 0; The semicolon seems inconsistent with the style of other derivations. (By the way, I am afraid that I am harming the signal to noise ratio of the bugtrack system by raising such incredibly trivial points as these. If this is the case, then please let me know by leaving a comment and I will stop submitting bug reports unless they represent a non-trivial problem)" peterderivaz D9 (K1003) v13 924 8.5.3.1.7: missing bottom picture boundary check Text D9 (K1003) v13 defect bbross closed 2012-12-21T10:43:31+01:00 2013-01-14T17:38:33+01:00 "To match HM, – If ( yP >> Log2CtbSizeY ) is equal to ( yPRb >> Log2CtbSizeY ), and xPRb is less than pic_width_in_luma_samples, the following applies. would have to be changed to – If ( yP >> Log2CtbSizeY ) is equal to ( yPRb >> Log2CtbSizeY ), yPRb is less than pic_height_in_luma_samples, and xPRb is less than pic_width_in_luma_samples, the following applies. " stefane D9 (K1003) v13 927 Mismatch HM/WD in motion vector candidate derivation Text D9 (K1003) v13 defect bbross closed 2012-12-21T16:28:38+01:00 2013-01-16T17:57:43+01:00 "In 8.5.3.1.6, step 7 of candidate A derivation, the condition: ''DiffPicOrderCnt( refPicListA[ refIdxA ], RefPicListX[ refIdxLX ] ) is not equal to 0'' is missing before the calculation of the rescale factor. This condition is present for the candidate B derivation, and for the temporal merge candidate derivation. It is also done in the HM for all these cases. I suggest to modify the HM as in the joined file." forayr D9 (K1003) v13 930 """short_term_ref_pic_set_idx"" is undefined when Ceil(Log2(num_short_term_ref_pic_sets)) is equal to 0." Text D9 (K1003) v13 defect bbross closed 2012-12-25T07:36:13+01:00 2013-01-14T17:39:41+01:00 "In the WD, ""short_term_ref_pic_set_idx"" is undefined when Ceil(Log2(num_short_term_ref_pic_sets)) is equal to 0. I suggest to append ""When not present, the value of short_term_ref_pic_set_idx is inferred to be equal to 0."" to the end of its defnition. For reference, in HM9.1 TDecCavlc::parseSliceHeader(), ""short_term_ref_pic_set_idx"" is defined bellow; if (numBits > 0) { READ_CODE( numBits, uiCode, ""short_term_ref_pic_set_idx"");} else { uiCode = 0; }" tajime D9 (K1003) v13 933 Bug in collocated motion vector prediction Text D9 (K1003) v13 defect bbross closed 2012-12-31T11:29:54+01:00 2013-01-14T17:41:10+01:00 "In 8.5.3.1.8 Derivation process for collocated motion vectors The below text – If DiffPicOrderCnt( currPic, pic ) is less than or equal to 0 for every picture pic in every reference picture list of the current slice should be changed to – If DiffPicOrderCnt( pic, currPic ) is less than or equal to 0 for every picture pic in every reference picture list of the current slice HM 9.1 is working properly according to the change." naveensr D9 (K1003) v13 936 description of hrd_op_set_idx has conflicting information Text D9 (K1003) v13 defect bbross closed 2013-01-04T23:42:04+01:00 2013-01-14T17:43:06+01:00 "The WD contains the following in the description of hrd_op_set_idx[i] In bitstreams conforming to this version of this Specification, the value of hrd_op_set_idx[ i ] shall be equal to 0. Although the value of hrd_op_set_idx[ i ] is required to be less than or equal to 1 in this version of this Specification, decoders shall allow other values of hrd_op_set_idx[ i ] in the range of 0 to 1023 to appear in the syntax. The first sentence says the value ""shall be equal to 0."" The second sentence says ""is required to be less than or equal to 1 ..."" The second sentence adds conflicting information by allowing for a value of 1 that is prohibited by the first sentence. It is suggested that the second sentence be shortened to ""Decoders shall allow other values ..."" " dthoang D9 (K1003) v13 937 Filtering process of neighbouring samples, Equation 8-30 and 8-32, operation precedence issue Text D9 (K1003) v13 defect bbross closed 2013-01-07T04:05:31+01:00 2013-01-17T14:56:30+01:00 "Current spec for equation 8-30: pF[ −1 ][ y ] = p[ −1 ][ −1 ] + ( ( y + 1 )*( p[ −1 ][ 63 ] − p[ −1 ][ −1 ] ) + 32 ) >> 6 Under the spec table 5-1 precedence, this reads as: pF[ −1 ][ y ] = '''('''p[ −1 ][ −1 ] + ( ( y + 1 )*( p[ −1 ][ 63 ] − p[ −1 ][ −1 ] ) + 32 )''')''' >> 6 However, it should be: pF[ −1 ][ y ] = p[ −1 ][ −1 ] + '''(''' ( ( y + 1 )*( p[ −1 ][ 63 ] − p[ −1 ][ −1 ] ) + 32 ) >> 6 ''')''' The equation 8-32 is with the same issue." conrad.ho D9 (K1003) v13 938 8.4.4.2.2 : Wrong value set for chroma sample substitution when all p[] pixels are marked as not available Text D9 (K1003) v13 defect bbross closed 2013-01-07T10:35:52+01:00 2013-01-17T14:59:02+01:00 "In chapter 8.4.4.2.2, the substitution is described as following : ""The values of the samples p[ x ][ y ] with x = −1, y = −1..nT*2−1 and x = 0..nT*2−1, y = −1 are modified as follows: – If all samples p[ x ][ y ] with x = −1, y = −1..nT*2−1 and x = 0..nT*2−1, y = −1 are marked as ""not available for intra prediction,"" the value ( 1 << ( '''BitDepthY''' − 1 ) ) is substituted for the values of all samples p[ x ][ y ]."" This is applied for luma and chroma pixels. For chroma pixels, I think the value to be used should be : ( 1 << ( '''BitDepthC''' − 1 ) ) " Jing-Jing Chung D9 (K1003) v13 948 wavefront availableFlagT derivation when PicWidthInCtbsY is 2 and pic_width_in_luma_samples%CtbSizeY is not zero Text D9 (K1003) v13 defect bbross closed 2013-01-11T12:33:12+01:00 2013-01-16T18:00:41+01:00 "According to Text ( xT, yT ) = ( x0 + 2 << Log2CtbSizeY − 1, y0 − 1 ) (9-3) when PicWidthInCtbsY is 2 and pic_width_in_luma_samples%CtbSizeY is not zero, (xT, yT) will be out of picture boundary, and availableFlagT should be FALSE. But in HM-9.1, it only checks availability of top-right coding tree block, and availableFlagT will be TRUE. This discrepancy should be fixed in HM or Text " mqiu D9 (K1003) v13 950 "Typo in the section 6.3 ""Spatial subdivision of pictures, slices, ...""" Text D9 (K1003) v13 defect bbross closed 2013-01-14T10:26:27+01:00 2013-01-16T17:59:32+01:00 "In the section 6.3. the following sentence is present: As another example, a picture may be divided into two tiles separated by a tile boundary as shown in Figure 6.5. According to the figure 6.5, the two tiles are separated by vertical boundary and not by horizontal. So, I suggest replacing 'horizontal' with 'vertical'." shevach D9 (K1003) v13 952 syntax function mvd_coding arguments are not used Text D9 (K1003) v13 defect bbross closed 2013-01-16T08:21:57+01:00 2013-01-16T17:03:40+01:00 "mvd_coding has the following header format:[[BR]] mvd_coding( x0, y0, refList ) {[[BR]] But the input parameters are never used anywhere, so it could be changed to:[[BR]] mvd_coding( ) {" pieterkapsenberg D9 (K1003) v13 939 low_delay_hrd_flag[i] present even when fixed_pic_rate_within_cvs_flag[i] == 1 Text D9 (K1003) v13 enhancement bbross closed 2013-01-09T00:29:54+01:00 2013-01-09T03:11:59+01:00 "low_delay_hrd_flag[i] is present even when fixed_pic_rate_within_cvs_flag[i] == 1. Compare this to fixed_pic_rate_within_cvs_flag[i], which is not present if fixed_pic_rate_general_flag[i] == 1, in which case fixed_pic_rate_within_cvs_flag[i] is inferred to be 1. For consistency, it is suggested that low_delay_hrd_flag[i] be present only if fixed_pic_rate_within_cvs_flag[i] == 0 and that it be inferred to be equal to 0 when fixed_pic_rate_within_cvs_flag[i] == 1." dthoang D9 (K1003) v13 926 Editorial items in v13 Text D9 (K1003) v13 defect bbross closed 2012-12-21T15:39:33+01:00 2013-01-14T17:49:11+01:00 "* 3 occurrences of ""'''neighboring'''"" (U.S.) in spec whereas the rest use ""'''neighbouring'''"" * '''Session 8.7.2.3''' PredFlagL0[ xB, yB ] + PredFlagL1[ xB, yB ] -> PredFlagL0[ xB ][ yB ] + PredFlagL1[ xB ][ yB ] * '''Session 8.7.2.4.7''' pcm_loop_filter_disable_flag is equal to 1 and pcm_flag[ xQj ][ yQj ]. -> pcm_loop_filter_disable_flag is equal to 1 and pcm_flag[ xQj ][ yQj ] '''is equal to 1'''. * '''Session 8.4.4.2.2''' ... and x = 0..nT*2−1, y = −1 are marked as ""not available for intra prediction,"" -> ... and x = 0..nT*2−1, y = −1 are marked as ""not available for intra prediction'''"",''' * '''Session 7.4.2.3''' When '''tiles_enable_flag''' is equal to 1 and ... -> When '''tiles_enabled_flag''' is equal to 1 and ... " sue.naing D9 (K1003) v13 932 Collection of minor edits for rev13 Text D9 (K1003) v13 defect bbross closed 2012-12-29T23:27:19+01:00 2013-01-16T17:58:49+01:00 "The definition in 3.152 for transform unit talks of 32x22 instead of 32x32 (occurs twice). In 6.4.1 ""Derivation process for z-scan order block availability"" the condition ""xN is greater than pic_width_in_luma_samples"" should be ""xN is greater than or equal to pic_width_in_luma_samples"" and similarly for yN. In 8.5.2 ""Inter prediction process"" modfied should be modified. In 8.5.3 ""Decoding process for prediction units in inter prediction mode"" the assignments in 8-61 (and 8-62,8-63,8-64,8-65,8-66) should change from MvL0[x][y]=mvL0 to MvL0[xC+x][yC+y]=mvL0. In several places in 8.5.3.1.6 ""Derivation process for motion vector predictor candidates"" the text uses refIdxLX[xAk][yAk] instead of RefIdxLX[xAk][yAk]. Similarly, refIdxLY is used instead of RefIdxLY. Note that refIdxLX (with a lower case r) is an input parameter, while RefIdxLX is an array. In 8.5.3.1.7 ""Derivation process for temporal luma motion vector prediction"" there is a check ""xPRb is less than pic_width_in_luma_samples"", and there should be a similar check for yPRb. In 8.5.4.2 ""Decoding process for chroma residual blocks"" split_transform_flag[xB0][yB0][trafoDepth] should be split_transform_flag[xC+xB0][yC+yB0][trafoDepth]. (Occurs twice) " peterderivaz D9 (K1003) v13 941 Blank cell in table 9-37 Text D9 (K1003) v13 defect bbross closed 2013-01-09T13:54:05+01:00 2013-01-16T18:02:08+01:00 "The entry for cell ""ref_idx_l0, ref_idx_l1"" for binIdx=4 is blank. " rikallen D9 (K1003) v4 890 wrong value of log2TrafoSize in transform unit syntax 7.3.8.10 Text D9 (K1003) v4 defect bbross closed 2012-12-06T14:07:52+01:00 2012-12-06T14:40:40+01:00 "In the current text, log2TrafoSize is used for the third argument when residual_coding for chroma is called in the following code : if( log2TrafoSize > 2 ) { if( cbf_cb[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, log2TrafoSize, 1 ) if( cbf_cr[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, log2TrafoSize, 2 ) } Since the spec defines only the format 4:2:0 for the moment, the size of chroma transform block is half of that of luma. So the spec should be changed to : if( log2TrafoSize > 2 ) { if( cbf_cb[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, log2TrafoSize - 1, 1 ) if( cbf_cr[ x0 ][ y0 ][ trafoDepth ] ) residual_coding( x0, y0, log2TrafoSize - 1, 2 ) }" PhuongNguyen D9 (K1003) v4 806 Typo in calculation of dcVal Text D9 (K1003) v4 defect bbross closed 2012-10-22T17:05:58+02:00 2012-11-30T14:58:21+01:00 "Calculation of dcVal (equation 8-39 in section 8.4.4.2.5): Substitute nT for nS." engelhardt D9 (K1003) v4 807 Missing clip after reconstruction Text D9 (K1003) v4 defect bbross closed 2012-10-22T19:00:23+02:00 2012-10-23T06:29:20+02:00 "- According to Frank Bossen (see http://mailman.rwth-aachen.de/mailman/private/jct-vc/2011-November/002445.html), the output of the 2D 32x32 idct can be on 11 bits for a 8bit ""normal"" bitstream after the right shift by 20-8. - In JCTVC-K1003_v3, there is no clipping operation in ""8.6.5 Picture construction process prior to in-loop filter process"" after the reconstruction. - In the reference decoding software, there is a clip operation (see TDecCu.cpp line 485, 557 and 703) after the reconstruction. I suggest a call to Clip() is added in section 8.6.5 to avoid overflows from 11 bits residuals. Without this, for corrupted or evil bitstreams, there is a mismatch between HM and D9." jonharper D9 (K1003) v4 808 Table formatting issue in Table 7-10 Text D9 (K1003) v4 defect bbross closed 2012-10-22T19:52:24+02:00 2012-11-30T15:12:02+01:00 Part of the bottom border is missing in Table 7-10 of JCTVC-K1003_v4.doc junxu D9 (K1003) v4 809 Several typos in WD9 Text D9 (K1003) v4 defect bbross closed 2012-10-22T20:56:43+02:00 2012-11-30T15:12:02+01:00 "1. Section 8.4.4.2.3 ""Output of this process are: – filtered samples pF[ x ][ y ],. with x, y = -1..2*nT-1."" --> extra period after comma. 2. Section 8.4.4.2.3 Inconsistent variable names:""intraHorVerDistThres"", ""intraHorVerDistThresh"". 3. Equation 8-242 ""with i = 0..nT, j = 0..nT"" should be ""with i = 0..nT-1, j = 0..nT-1"" since ""a (nT)x(nT) array transformBlock"" can not have an index from 0 to nT in any dimension. 4. Equation 8-243 ""with i = 0..nT, j = 0..nT"" should be ""with i = 0..nT-1, j = 0..nT-1"" since ""a (nT)x(nT) array transformBlock"" can not have an index from 0 to nT in any dimension. 5. Section 9.2.1, ""Error! Reference source not found.""" junxu D9 (K1003) v4 811 Typo in Table: 7.3.8.4 Coding quadtree syntax Text D9 (K1003) v4 defect bbross closed 2012-10-23T20:04:43+02:00 2012-11-30T15:12:02+01:00 "There is an extra ""("" in the if statement below: ""if( ( cu_qp_delta_enabled_flag && log2CbSize >= Log2MinCuQpDeltaSize ) {"" Should be : ""if( cu_qp_delta_enabled_flag && log2CbSize >= Log2MinCuQpDeltaSize ) {"" " xinjun D9 (K1003) v4 812 typo in HRD description hrd_parameters_sub_layer Text D9 (K1003) v4 defect bbross closed 2012-10-23T20:25:16+02:00 2012-11-30T15:12:02+01:00 "Section C.1 refers to ""hrd_parameters_sub_layer( HighestTid )"", which is a typo, and should be ""sub_layer_hrd_parameters( HighestTid )"" as specified in hrd_parameters() syntax in E.1.2 " xinjun D9 (K1003) v4 814 relative pixel location in edge filtering process calculated from absolute pixel location Text D9 (K1003) v4 defect bbross closed 2012-10-25T11:09:10+02:00 2012-11-30T15:12:02+01:00 "In section 8.7.2.4.1 the luma location (xDk, yDm) is computed by: ""yDm set equal to yC+( m << 3 ), m = 0..nD − 1"" and ""xDk set equal to xC + ( k << 2 ), k = 0..nD*2 − 1"". In the following text (xDk, yDm) is used as relative luma location to the top left sample of the current luma coding block. Therefore the addition of (xC, yC) should be removed in the above equations. The same mismatch can be found in the calculation of the relative chroma position in the same section and the relative luma/chroma positions for the horizontal filtering process in section 8.7.2.4.2. " jbrandenburg D9 (K1003) v4 816 8.4.4.2.5 : wrong index for dcVal calculation Text D9 (K1003) v4 defect bbross closed 2012-10-29T08:42:15+01:00 2012-11-12T15:07:01+01:00 "In chapter 8.4.4.2.5 of JCTVC-K1003_v4, the variable nS is used for the calculation of dcVal. nS is not defined in this chapter, but earlier as 1 << Log2CbSize. I think there is a typo there. nT (the transform block size) should be used instead of nS." Jing-Jing Chung D9 (K1003) v4 817 intraPartMode in 8.4.4.2.6 Text D9 (K1003) v4 defect bbross closed 2012-10-29T18:12:25+01:00 2012-11-30T15:12:02+01:00 "In 8.4.4.2.6: Typo in 2c): intraPartMode -> intraPredMode For reasons of consistency the sentence should be rewritten to: ""If intraPredMode is equal to 26..."" The last sentence of this subsection must be changed accordingly." engelhardt D9 (K1003) v4 823 Typo in chroma deblocking vertical edge filtering grid Text D9 (K1003) v4 defect bbross closed 2012-11-02T07:40:03+01:00 2012-11-30T15:22:51+01:00 "In section 8.7.2.4.1, chroma vertical edge deblocking grid computation condition being checked is ""(( yDm >> 3 ) << 3) is equal to yDm"". Should this be ""(( xDk >> 3 ) << 3) is equal to xDk""? Accoding to doc present in ticket 711 [http://hevc.kw.bbc.co.uk/trac/ticket/711] vertical edge filtering checks for alignment of xDk." harish.mahendrakar D9 (K1003) v4 825 Editorial items Text D9 (K1003) v4 defect bbross closed 2012-11-04T08:26:10+01:00 2012-11-30T15:22:51+01:00 "In K1003-v7: Section 8.4.4.1: ""Depending splitFlag, the following applies:"" should be ""Depending on splitFlag, the following applies:"" Section 8.4.4.2.1: Eqn (8-27): ""yBN = yB +y"" should be ""yBN = yB + y"" Section 8.4.4.2.6: Eqn (8-49): ""iFact = ( ( y + 1 )*intraPredAngle ) && 31"" should be ""iFact = ( ( y + 1 )*intraPredAngle ) & 31"" Near eqns (8-45) and (8-53): Two instances of the word 'extented' should each be replaced by 'extended'. Eqn (8-57): ""iFact = ( ( x + 1 )*intraPredAngle ) && 31"" should be ""iFact = ( ( x + 1 )*intraPredAngle ) & 31"" " crosewarne D9 (K1003) v4 830 mismatch between WD and HM for inferring significant_coeff_flag at last position in TU Text D9 (K1003) v4 defect bbross closed 2012-11-07T21:57:41+01:00 2012-11-30T15:22:51+01:00 "There seems to be a mis-match between semantics, syntax table and HM regarding whether significant_coeff_flag should be inferred for the last position in the TU. In the WD semantics it says that significant_coeff_flag is inferred for the last position; however, this is not the case in HM-9.0. Note that this also means the ctxIdxMap must be defined for i=15 (ctxIdxMap[15]=8), since there can be a possible to signal significant_coeff_flag at (3,3) position of 4x4 TU. In WD9 (7.4.9.11 Residual coding semantics): When significant_coeff_flag[ xC ][ yC ] is not present, it is inferred as follows. – '''If ( xC, yC ) is the last significant location ( LastSignificantCoeffX, LastSignificantCoeffY ) in scan order''' or both of the following conditions are true, significant_coeff_flag[ xC ][ yC ] is inferred to be equal to 1. In HM-9.0, significant_coeff_flag is only inferred when numNonzero=0; however, for last position numNonZero is set to 1. if( iScanPosSig == (Int) uiScanPosLast ) { lastNZPosInCG = iScanPosSig; firstNZPosInCG = iScanPosSig; iScanPosSig--; pos[ numNonZero ] = uiBlkPosLast; '''numNonZero = 1;''' } ... if( uiSigCoeffGroupFlag[ iCGBlkPos ] ) { if( iScanPosSig > iSubPos | | iSubSet == 0 | | '''numNonZero''' ) { uiCtxSig = TComTrQuant::getSigCtxInc( patternSigCtx, uiScanIdx, uiPosX, uiPosY, blockType, uiWidth, uiHeight, eTType ); m_pcTDecBinIf->decodeBin( uiSig, baseCtx[ uiCtxSig ] ); } else { uiSig = 1; } }" vsze D9 (K1003) v4 836 Clip1 of recSamples (Section 8.6.5, Equation 8-270) Text D9 (K1003) v4 defect bbross closed 2012-11-12T22:20:37+01:00 2012-11-13T13:48:21+01:00 "A Clip1 seems to be missing for recSamples (output of reconstruction before in-loop filter). " madhukar D9 (K1003) v4 838 About vps_sub_layer_ordering_info_present_flag related syntax Text D9 (K1003) v4 defect bbross closed 2012-11-13T13:33:37+01:00 2012-11-30T15:32:40+01:00 "The spec said ""vps_sub_layer_ordering_info_present_flag equal to 1 specifies that vps_max_dec_pic_buffering[ i ], vps_max_num_reorder_pics, and vps_max_latency_increase[ i ] are present for vps_max_sub_layers_minus1 + 1 sub-layers"". Thus the syntax is wrong. Current: for( i = ( vps_sub_layer_ordering_info_present_flag ? vps_max_sub_layers_minus1 : 0 ); i <= vps_max_sub_layers_minus1; i++ ) Correction: for( i = ( vps_sub_layer_ordering_info_present_flag ? '''0 : vps_max_sub_layers_minus1''' ); i <= vps_max_sub_layers_minus1; i++ ) " conrad.ho D9 (K1003) v4 815 log2PbSize is not used in Sec 8.4.2 Text D9 (K1003) v4 defect bbross closed 2012-10-29T03:53:01+01:00 2012-11-30T15:05:38+01:00 "In Section 8.4.2 of WD9 (K1003v4), log2PbSize is listed as an input to the derivation process for luma intra prediction mode. However, it is not actually referenced elsewhere in Section 8.4.2. It is suggested that this input be removed as it appears not needed by the process described in Section 8.4.2. " chyeo D9 (K1003) v4 824 [TEXT] Add QuadHD to table A-3& A-4 Text D9 (K1003) v4 task bbross closed 2012-11-02T19:56:05+01:00 2012-11-30T15:05:38+01:00 In the last meeting, it was agreed to add QuadHD (3840x2160) to table A-3&A-4 in the next draft. I didn;t see this in the current K1003 draft. yasser_syed D9 (K1003) v9 783 different Text and HM initValue for ref_idx_l[01] Text D9 (K1003) v9 defect bbross closed 2012-09-27T20:49:54+02:00 2012-11-30T15:25:29+01:00 "Text: initValue = {102, 118, 118, 118}; HM: static const UChar INIT_REF_PIC[3][NUM_REF_NO_CTX] = { { 153, 153 }, { 153, 153 }, { CNU, CNU }, }; " sorin D9 (K1003) v9 839 Error in strong intra smoothing formulas. Text D9 (K1003) v9 defect bbross closed 2012-11-13T20:39:36+01:00 2012-11-30T15:25:29+01:00 "There is a mismatch between the WD and the HM software regarding strong intra smoothing. Specifically, the +32 for rounding in the following formulas should be added after the multiplication. The additional parenthesis below would resolve the mismatch. pF[ −1 ][ y ] = p[ −1 ][ −1 ] + (( y + 1 )*(p[ −1 ][ 63 ] − p[ −1 ][ −1 ]) + 32 ) >> 6 for y = 0..62 (8-30) pF[ x ][ −1 ] = p[ −1 ][ −1 ] + (( x + 1 )*(p[ 63 ][ −1 ] − p[ −1 ][ −1 ]) + 32 ) >> 6 for x = 0..62 (8-32) " bheng D9 (K1003) v9 842 8.5.3 minor editorial fix Text D9 (K1003) v9 defect bbross closed 2012-11-14T04:08:34+01:00 2012-11-30T15:25:29+01:00 "Subclause 8.5.3 is only invoked with nPbW and nPbH being specified in luma samples and within the body of the subclause nPbW and nPbH these are described as being in luma samples, so the interface to this subclause should also describe these parameters as being in luma samples. In K1003-v9: 8.5.3 Decoding process for prediction units in inter prediction mode: ... - a variable nPbW specifying the width of the current prediction block, - a variable nPbH specifying the width of the current prediction block, ... Replace with: ... - a variable nPbW specifying the width of the current prediction block in luma samples, - a variable nPbH specifying the width of the current prediction block in luma samples, ... " crosewarne D9 (K1003) v9 844 Deblocking filter typos Text D9 (K1003) v9 defect bbross closed 2012-11-17T01:06:22+01:00 2012-11-30T15:25:29+01:00 "8.7.2.3: Derivation process of boundary filtering strength ""where xL is equal to ((( xC + xDi ) >> 3) << 3) + ((( xC + xDi ) >> 3) & 1) * 7"" Is this a removal oversight from Draft 9? The same condition was removed from 8.5.3.1.2: Derivation process for spatial merging candidates. 8.7.2.4.3: Decision process for luma block edges ""The variable dqp is set equal to 2*dpq0."" Should be dpq instead of dqp. 8.7.2.4.5: Filtering process for chroma block edges ""Q = Clip3( 0, 53, QPC + 2 * ( bS − 1 ) + ( tc_offset_div2 << 1 ) )"" Should be qPi instead of QPC. 8.7.2.4.7: Filtering process for a luma sample ""each of the filtered sample values, pi' with i = 0..nDp−1, is substituted by the corresponding input sample value pi"" Correct, but setting nDp = 0 is simpler. 8.7.2.4.1: Vertical edge filtering process: Quoting the unanswered question from Harish Mahendrakar which seems pertinent (I'd like to know the answer as well): HEVC draft mentions a grid of 8x8 for chroma deblocking with filtering done for 4 pixels at a time. What is the need for an 8x8 grid in chroma? Since chroma deblocking uses only 2 pixels each on both sides of the edge being filtered and only one pixel on each side is modified a grid of 8x8 is not needed. In luma filtering without 8x8 grid, all vertical edges (or all horizontal edges) cannot be filtered in parallel because, edge at a given 4 pixel boundary will need output from previous filter. But in chroma this problem does not arise because only one pixel on each side is modified. So 4x4 grid for chroma will not have any problems in multi-core implementation and also will ensure all intra edges (at luma 8x8 grid) will be filtered in both luma and chroma. Or was 8x8 grid for chroma specified to keep the computational complexity down? " laurent.birtz@… D9 (K1003) v9 846 Missing CABAC memorization flowchart Text D9 (K1003) v9 defect bbross closed 2012-11-19T12:59:25+01:00 2012-11-30T15:25:29+01:00 "Figure 9 4 – Illustration of CABAC memorization process (informative) is broken: ""Error! Objects cannot be created from editing field code"" and needs to be re-inserted." bbross D9 (K1003) v9 847 Residual semantic bugs Text D9 (K1003) v9 defect bbross closed 2012-11-19T23:24:25+01:00 2012-11-30T15:25:29+01:00 "7.4.9.11: Residual coding semantics: In the description of coded_sub_block_flag: ""If (xS, yS) is equal to (0, 0), at least one of the 16 significant_coeff_flag syntax elements is present for the sub-block at location (xS, yS). What if only the first TB coefficient is non-zero? In that case its value would be inferred from last_significant_coeff and no significant_coeff_flag would be present. 7.4.2.2: Sequence parameter set RBSP semantics: The usage of ScanOrder is inconsistent. Description for log2_diff_max_min_transform_block_size: ""For the variable log2BlockSize ranging from Min( 2, Log2MinTrafoSize − 2) to 3, inclusive, the scanning order array ScanOrder is derived as follows"". Suppose 4x4 transforms are allowed. Then, Log2MinTrafoSize == 2, the range for log2BlockSize is [0, 3] and the 4x4 array is mapped at index 0 in ScanOrder. However, in 7.3.9.11, ScanOrder[2] is used to derive the scan order of the 16 coefficients: ""xC = ( xS << 2 ) + ScanOrder[ 2 ][ scanIdx ][ n ][ 0 ]"". ScanOrder[2] does not correspond to the 4x4 transform. 7.4.6: Scaling list data semantics ""scaling_list_pred_mode_flag[ sizeId ][ matrixId ] equal to 0 specifies that the values of the scaling list are the same as the values of a reference scaling list."" The name has the opposite meaning of the usage. 7.3.6: Scaling list data syntax: The interaction between scaling_list_delta_coef and scaling_list_dc_coef_minus8 is suspicious. There are 64 scaling_list_delta_coef values present even if scaling_list_dc_coef_minus8 is present. First, ScalingFactor is built from scaling_list_delta_coef: ""ScalingFactor[ 3 ][ matrixId ][ x * 4 + k ][ y * 4 + j ] = ScalingList[ 3 ][ matrixId ][ i ]"". Then, the first value in ScalingFactor is overridden: ""ScalingFactor[ 3 ][ matrixId ][ 0 ][ 0 ] = scaling_list_dc_coef_minus8[ 1 ][ matrixId ] + 8"". It seems to me that the only sensible value for the first scaling_list_delta_coef is 0 since scaling_list_dc_coef_minus8 covers the full range of possible values for the first entry in ScalingFactor. I presume that the first scaling_list_delta_coef is present only to ease the parsing of the syntax. If that's the case, I suggest to require the first scaling_list_delta_coef value to be 0. The current logic is confusing and slows down the parsing operation. " laurent.birtz@… D9 (K1003) v9 848 Inter prediction semantic bugs Text D9 (K1003) v9 defect bbross closed 2012-11-19T23:55:31+01:00 2012-11-21T12:03:12+01:00 "8.5.3.1: Derivation process for motion vector components and reference indices The process does not assign a value for mvL0 and mvL1 when their list is unused. To my knowledge and unlike H.264, the HEVC specification does not assume anywhere that the MV is null in that case but to be formal a value should be assigned regardless. 7.4.9.6: Prediction unit semantics The value of ""merge_idx"" is unrestricted (not bounded by MaxNumMergeCand anywhere as far as I can tell). " laurent.birtz@… D9 (K1003) v9 849 Entropy coding typos Text D9 (K1003) v9 defect bbross closed 2012-11-20T00:02:54+01:00 2012-11-30T15:25:29+01:00 "Table 9-28 is not referred to anywhere. In Table 9-63, missing value for i == 15 (and typo Specifcation)." laurent.birtz@… D9 (K1003) v9 850 Mismatch between WD and HM in equation (7-67) Text D9 (K1003) v9 defect bbross closed 2012-11-20T11:22:32+01:00 2012-11-30T15:25:29+01:00 "In K1003-v9: Session 7.4.8.4 (equation 7-67): ChromaOffsetL0[ i ][ j ] = Clip3( −128, 127, ( delta_chroma_offset_l0[ i ][ j ] − ( ( 128 * ChromaWeightL0[ i ][ j ] ) >> ChromaLog2WeightDenom ) '''− 128''' ) ) In HM9.0.1: TDecCavlc::xParsePredWeightTable(): ChromaOffsetL0[ i ][ j ] = Clip3( −128, 127, ( delta_chroma_offset_l0[ i ][ j ] − ( ( 128 * ChromaWeightL0[ i ][ j ] ) >> ChromaLog2WeightDenom ) '''+ 128''' ) )" sue.naing D9 (K1003) v9 851 condition for numMVPCandLX in 8.5.3.1.5 Text D9 (K1003) v9 defect bbross closed 2012-11-20T11:44:55+01:00 2012-11-30T15:25:29+01:00 "Session 8.5.3.1.5 stated: ... ""Otherwise (numMVPCandLX is greater than or equal to 2), all motion vector predictor candidates mvpListLX[ idx ] with idx greater than 1 are removed from the list."" However, when numMVPCandLX is equal to 2, this process is unnecessary." sue.naing D9 (K1003) v9 852 Typo of slice illustration Text D9 (K1003) v9 defect bbross closed 2012-11-20T12:10:11+01:00 2012-11-30T15:25:29+01:00 "In section 6.3: The left side of the figure illustrates a case in which the picture only contains one slice, starting with an independent slice segment and followed by three dependent slice segments. ""three dependent slice segments"" should be ""four dependent slice segments"" according to Figure 6-5." xx.cai D9 (K1003) v9 853 Clarification for yCtb in Coding tree unit syntax Text D9 (K1003) v9 defect bbross closed 2012-11-20T12:12:11+01:00 2012-11-30T15:25:29+01:00 "In 7.3.9.2 Coding tree unit syntax ""yCtb = ( CtbAddrRS / '''PicHeightInCtbsY''' ) << Log2CtbSizeY"" Shouldn't PicHeightInCtbsY be PicWidthInCtbsY? ""yCtb = ( CtbAddrRS /''' PicWidthInCtbsY''') << Log2CtbSizeY"" ?" sue.naing D9 (K1003) v9 855 "Typo in 8.4.2 Derivation process for luma intra prediction mode" Text D9 (K1003) v9 defect bbross closed 2012-11-20T13:25:58+01:00 2012-11-30T15:25:29+01:00 "In session 8.4.2: Typo: “Otherwise, if N is equal to B and yB−1 is less than ( ( yB >> Log2CtbSizeY ) << Log2CtbSizeY ), '''intraPredModeB''' is set equal to Intra_DC."" should be “Otherwise, if N is equal to B and yB−1 is less than ( ( yB >> Log2CtbSizeY ) << Log2CtbSizeY ), '''candIntraPredModeB''' is set equal to Intra_DC."" Inconsistency: Missing “Output of this process” Formatting: Inconsistent font size in equation (8-23), (8-24) and (8-25). 1st elements have larger font size. " sue.naing D9 (K1003) v9 856 Typo in D9 v9 Text D9 (K1003) v9 defect bbross closed 2012-11-20T15:00:50+01:00 2012-11-30T15:25:29+01:00 "In K1003-v9: * '''Session 6.4.1:''' “.. z-scan order minBlockAddrCurr of the current '''blockis''' derived as follows.” should be “.. z-scan order minBlockAddrCurr of the current '''block is''' derived as follows.” * '''Session 7.3.9.8:''' ""transform_tree( x1, y0, x0, y0, log2TrafoSize − 1 trafoDepth + 1, 1 )"" should be ""transform_tree( x1, y0, x0, y0, log2TrafoSize − 1''',''' trafoDepth + 1, 1 )"" * '''Session 7.3.9.11:''' ""lastSubBlock = ( 1 << ( log2TrafoSize − 2 ) * ( 1 << ( log2TrafoSize − 2 ) ) − 1"" should be ""lastSubBlock = ( 1 << ( log2TrafoSize − 2 ) ''')''' * ( 1 << ( log2TrafoSize − 2 ) ) − 1"" * ''' Session 7.4.9.3:''' In table 7-8, inconsistent letter case used for ""Band offset"" and ""Edge Offset"" * ''' Session 8.4.4.2.6:''' “Figure 8-2 illustrates the total '''34''' intra angles” should be “Figure 8-2 illustrates the total '''33''' intra prediction angles” * '''Session 8.6.1: Equation(8-245):''' ""QPY = ( ( ( qPY_PRED + CuQpDelta +52+ 2*QpBdOffsetY )%( 52 + QpBdOffsetY ) ) − QpBdOffsetY"" should be ""QPY = '''~~(~~''' ( ( qPY_PRED + CuQpDelta +52+ 2*QpBdOffsetY )%( 52 + QpBdOffsetY ) ) − QpBdOffsetY " sue.naing D9 (K1003) v9 857 clarity of neighbouring samples description in 8.4.4.2.x Text D9 (K1003) v9 defect bbross closed 2012-11-20T19:34:11+01:00 2012-11-30T15:25:29+01:00 "Several places under 8.4.4.2 have 2 different descriptions for neighbouring samples locations: In sessions, * 8.4.4.2.1 & * 8.4.4.2.2, reference samples and neighbouring samples are described as: [[BR]] p[ x ][ y ] with x = −1, y = −1..nT*2−1 and x = 0..nT*2−1, y = −1 In sessions, * 8.4.4.2.3, * 8.4.4.2.4, * 8.4.4.2.5 & * 8.4.4.2.6 neighbouring/filtered samples are described as: [[BR]] p[ x ][ y ], with x, y = −1..2*nT−1 For clarity and consistency of the text, the descriptions should follow as in 8.4.4.2.1 and 8.4.4.2.2." sue.naing D9 (K1003) v9 858 Typo in syntax Text D9 (K1003) v9 defect bbross closed 2012-11-21T17:09:37+01:00 2012-11-30T15:25:29+01:00 "* Session 7.3.9.2 Coding tree unit syntax coding_tree_unit( xCtb, yCtb ) should be coding_tree_unit( ) * Session 7.3.9.5 Coding unit syntax prediction_unit( x0, y0, log2CbSize ) should be prediction_unit( x0, y0, ( 1 << log2CbSize ), ( 1 << log2CbSize ) ) * Session 8.5.3.1.5 mvpListLX[ mvp_lX_flag[ xP, yP ] ] should be mvpListLX[ mvp_lX_flag[ xP ][ yP ] ] " sue.naing D9 (K1003) v9 859 decoded_picture_hash() operator precedence issue Text D9 (K1003) v9 defect bbross closed 2012-11-21T19:05:06+01:00 2012-11-30T15:25:29+01:00 "for( cIdx = 0; cIdx < (chroma_format_idc == 0) ? 1 : 3; cIdx++ ) would result in an infinite loop... substitute with this: for( cIdx = 0; cIdx < (chroma_format_idc == 0 ? 1 : 3); cIdx++ ) This error is repeated in the pseudocode in ""Decoded picture hash SEI message semantics""" Parabola D9 (K1003) v9 860 inferSigCoeffFlag discrepancy with HM? Text D9 (K1003) v9 defect bbross closed 2012-11-21T19:56:55+01:00 2012-11-30T15:25:29+01:00 "We have code with very similar structure to the draft standard pseudocode. This pseudocode in the text seems incorrect: inferSigCoeffFlag = 0 if( ( i < lastSubBlock ) && ( i > 0 ) ) { coded_sub_block_flag[ xS ][ yS ] inferSigCoeffFlag = 1 } To make our implementation agree with HM, we had to do this instead: inferSigCoeffFlag = 0 if( ( i < lastSubBlock ) && ( i > 0 ) ) { coded_sub_block_flag[ xS ][ yS ] inferSigCoeffFlag = coded_sub_block_flag[ xS ][ yS ] } Now this could be indicative of a problem elsewhere in the draft standard description or possibly in a mistake our own implementation but we thought it worth flagging up. " Parabola D9 (K1003) v9 863 Ed: higlighting of display_orientation_repetition_period syntax element Text D9 (K1003) v9 defect bbross closed 2012-11-27T19:57:35+01:00 2012-11-30T15:25:29+01:00 In the SEI semantics the syntax element display_orientation_repetition_period is highlighted in bold multiple times at the beginning of a line. It should only be highlighted at the beginning of the section. ksuehring D9 (K1003) v9 864 sps_reserved_zero_bit still exists Text D9 (K1003) v9 defect bbross closed 2012-11-28T00:22:53+01:00 2012-11-30T15:25:29+01:00 "From the integration notes: Integrated the following decisions noted under JCTVC-K0120: o Move sps_temporal_nesting_flag to an earlier place to replace sps_reserved_zero_bit It seems that sps_temporal_nesting_flag was added at the new position, but sps_reserved_zero_bit hasn't been removed." ksuehring D9 (K1003) v9 896 dEp1 and dEq1 are not specified in 8.7.2.4.7 Text D9 (K1003) v9 defect bbross closed 2012-12-09T14:19:16+01:00 2012-12-28T19:08:11+01:00 In the section 8.7.2.4.7 (Filtering process for a luma sample) the input parameters dEp1 and dEq1 are not specified. I suppose that dEp1 and dEq1 should be replaced with dEp and dEq. shevach RExt D7 (Q1005) v8 1363 Log2MaxTrafoSize is not defined Text RExt D7 (Q1005) v8 defect closed 2015-01-26T14:49:22+01:00 2018-01-22T06:41:50+01:00 Specification of log2_max_transform_skip_block_size_minus2 refers to Log2MaxTrafoSize, but it is not defined anywhere in specification. gregory RExt D7 (Q1005) v8 1426 split_cu_flag specifies whether a coding quadtree is split into coding quadtrees. Text RExt D7 (Q1005) v8 defect closed 2015-10-20T08:06:10+02:00 2018-01-22T06:43:41+01:00 "In ""7.4.9.4 Coding quadtree semantics"" (pp.100 in H.265-201504), split_cu_flag[ x0 ][ y0 ] specifies whether a coding unit is split into coding units with ... Even though the coding unit is what the syntax wants to describe, split_cu_flag is for a coding quadtree and the resulting leaf (if any) is a coding unit. So, I think that it should be changed to split_cu_flag[ x0 ][ y0 ] specifies whether a coding quadtree is split into coding quadtrees with ... Thanks. " jk73.kim WD4 (F803) d6 233 [WD4] Issue in specification of Intra_Angular prediction mode Text WD4 (F803) d6 defect wjhan closed 2011-12-14T14:17:56+01:00 2012-02-17T10:33:47+01:00 "The current WD4 does not describe the intra angular prediction properly for IntraPredOrder greater than or equal to 18. In that case, the predictor obtained is a transposition of the expected result. Find attached a proposed revision of the Intra_Angular prediction mode specification (starting after the invAngle table). " tkunlin WD5 (G1103) d0 259 WD5 IntraPredModeC mistake? Text WD5 (G1103) d0 defect bbross closed 2011-12-29T12:58:06+01:00 2012-02-08T12:29:51+01:00 "In the WD5(G1103-d1) Talbe 8-4, I guess it have some mistake with HM-5.0. I have checked the function here, the function codeIntraDirChroma and parseIntraDirChroma see like use Table 8-5 always. The mistake in the Table 8-4 are: 1. intra_chroma_pred_mode=1 and IntraPredMode=2 or 3 2. intra_chroma_pred_mode=2 and IntraPredMode=3 " chenm003 WD5 (G1103) d2 267 WD5 Table 8-6 mistake Text WD5 (G1103) d2 defect bbross closed 2012-01-06T09:11:08+01:00 2012-01-18T19:21:14+01:00 Somebody change PLANAR_IDX from 34 to 0, but WD5 Table 8-6 not updated. chenm003 WD5 (G1103) d2 280 Semantics of num_ref_idx_l0_active_minus1 is incorrect. Text WD5 (G1103) d2 defect bbross closed 2012-01-11T22:58:07+01:00 2012-02-16T08:01:36+01:00 "Context: Page 60, section 7.4.3 'Slice Header semantics' The description of 'num_ref_idx_l0_active_minus1' still has wording that's taken from H.264, including (shudder) MBAFF. There are no field, frame or any other kind of macroblocks. I believe that all the text starting with 'The range of num_ref_idx_l0_active_minus1 is specified as ..' should be replaced with: The range of num_ref_idx_l0_active_minus1 shall be in the range of 0 to 15, inclusive. " hellman WD5 (G1103) d2 263 Some text bugs related to tiles in WD5 (G1103) d2 Text WD5 (G1103) d2 defect bbross closed 2012-01-04T18:28:59+01:00 2012-02-16T07:50:02+01:00 "1) The treeblock address conversion process as specified in subclause 6.4.1 is not invocated in anywhere in the WD. 2) The byte alignment syntax for independent tiles has the following problems 2.1) At least ""rbsp_trailingbits()"" should be ""rbsp_trailing_bits()"" 2.2) The byte alignment syntax byte_align( ), as used in APS syntax, should be used instead of rbsp_trailing_bits(). Note that the definition of byte_align( ) is missing in WD5d2. " yk WD5 (G1103) d2 264 Some text bugs related to wavefront parallel processing in WD5 (G1103) d2 Text WD5 (G1103) d2 defect bbross closed 2012-01-04T18:33:48+01:00 2012-02-16T07:51:08+01:00 " 1) entropy_coding_synchro is specified as “u(v)” coded, but the semantics does not say how. It should be “ue(v)” coded instead. 2) It is said that “The value of entropy_coding_synchro shall be in the range of 0 to tileWidthInLCUs−1, inclusive.” However, what if there are no tiles? What if tiles are of different widths? 3) cabac_istate_reset_flag is about CABAC flushing for wavefront parallel processing. It should not be present if entropy_coding_synchro is equal to 0. " yk WD5 (G1103) d2 270 Section 9.2 equation correction Text WD5 (G1103) d2 defect bbross closed 2012-01-06T17:17:21+01:00 2012-02-16T07:53:41+01:00 "Section 9.2: The derivation of tbAddrT should be: tbAddrT = cuAddress( x0 + (entropy_coding_synchro + 1) * ( 1 << Log2MaxCUSize ) − 1, y0 − 1 ) and the derivation of i when tile_boundary_independence_flag is equal to 0 should be: i = ( tbAddrRasterScan / picWidthInLCUs ) % ( num_substreams_minus1 + 1 ) " felix.henry WD5 (G1103) d2 276 SaoMaxDepth unknown in APS Text WD5 (G1103) d2 defect bbross closed 2012-01-11T10:49:31+01:00 2012-02-16T07:58:41+01:00 "An APS does not contain a pps_id or sps_id pointing to an active sequence parameter set. As a consequence, the sequence size is not known when parsing an APS, and SaoMaxDepth can not be computed as : SaoMaxDepth = Min( 4, Min( Floor( Log2( PicWidthInLCUs ) ), Floor( Log2( PicHeightInLCUs ) ) ) ) The coded SAO parameters can still be saved thanks to the sao_data_byte_count syntax element, and later parsed when SaoMaxDepth is known. But is it the wanted behaviour ? Shouldn't an APS contain a reference to a SPS ?" tkunlin WD5 (G1103) d2 279 Some text bugs related to tiles: derivation of columnWidth[] etc. in 7.4.2.1 Text WD5 (G1103) d2 defect bbross closed 2012-01-11T19:03:09+01:00 2012-02-16T08:02:55+01:00 " Besides editorial bugs, all the four equations are not complete by missing one value for each array not covered. Suggested changes are as follows. 1. In the following sentence, replace ""num_tile_columns_minus1"" with ""num_tile_columns_minus1 + 1"": ""The vector columnWidth[ ], specifying the width for every of the num_tile_columns_minus1 columns in units of treeblocks, is derived as follows."" 2. In the equation for derivation of columnWidth[] (BTW, the equation number is incorrect, therefore citing the equation number does not work - same for many other equations), replace ""for( i = 0; i < num_tile_columns_minus1; i++ )"" with ""for( i = 0; i <= num_tile_columns_minus1; i++ )"". 3. In the following sentence, replace ""num_tile_rows_minus1"" with ""num_tile_rows_minus1 + 1"" ""The vector rowHeight[ ], specifying the height for every of the num_tile_rows_minus1 rows in units of treeblocks, is derived as follows."" 4. In the equation for derivation of rowHeight[], replace ""for( i = 0; i < num_tile_rows_minus1; i++ )"" with ""for( i = 0; i <= num_tile_rows_minus1; i++ )"". 5. Replace the equation for derivation of colBd[] with the following: colBd[0] = 0 for( i = 0; i <= num_tile_columns_minus1; i++ ) colBd[i+1] = colBd[i] + columnWidth[i] 6. Replace the equation for derivation of rowBd[] with the following: rowBd[0] = 0 for( i = 0; i <= num_tile_rows_minus1; i++ ) rowBd[i+1] = rowBd[i] + rowHeight[i] " yk WD5 (G1103) d2 281 num_ref_idx_l0/l1_default_active_minus1 range is too large Text WD5 (G1103) d2 defect bbross closed 2012-01-12T00:08:54+01:00 2012-02-09T05:32:45+01:00 "Context: page 56, section 7.4.2.2 'Picture Parameter set semantics' Description for num_ref_idx_l0/l1_default_active_minus1 says that the range is 0 to 31, inclusive. As confirmed at the last meeting, the maximum number of reference pictures is 16, so this range should be 0 to 15, inclusive. Note that this is in two places (one for l0, one for l1). " hellman WD5 (G1103) d4 289 Text bug related to Temporal MV prediction (8.4.2.1.8) Text WD5 (G1103) d4 defect bbross closed 2012-01-19T10:05:20+01:00 2012-01-19T22:27:07+01:00 " [Reference text taken from WD5-d5] In step 6 of 8.4.2.1.8 (Derivation process for temporal luma motion vector prediction), the value of N is not correctly defined in “with N being value of RefIdxLX”. It was suggested by the editor team to replace the following paragraph: - If all PicOrderCnts of pictures in all reference picture lists are smaller than PicOrderCnt( currPic ), the motion vector mvCol, the reference index refIdxCol and ListCol are set equal to MvLN[ xPCol ][ yPCol ], RefIdxLN[ xpCol ][ ypCol ] and LN, respectively, with N being value of RefIdxLX. - Otherwise (one of PicOrderCnt of pictures in all reference picture lists are larger than PicOrderCnt( currPic ) ), the motion vector mvCol, the reference index refIdxCol and ListCol are set equal to MvLN[ xPCol ][ yPCol ], RefIdxLN[ xpCol ][ ypCol ] and LN, respectively, with N being value of collocated_from_l0_flag. by this one: - If PicOrderCnt( pic ) of every picture pic in every reference picture list is less than or equal to PicOrderCnt( currPic ), the motion vector mvCol, the reference index refIdxCol and ListCol are set equal to MvLX[ xPCol ][ yPCol ], RefIdxColLX and LX, respectively, with X being the value of X this process is invoked for. - Otherwise (PicOrderCnt( pic ) of at least one picture pic in at least one reference picture list is greater than PicOrderCnt( currPic )), the motion vector mvCol, the reference index refIdxCol and ListCol are set equal to MvLN[ xPCol ][ yPCol ], RefIdxColLN and LN, respectively, with N being the value of collocated_from_l0_flag. " iperroux WD5 (G1103) d6 293 refernce picture list modification semantics Text WD5 (G1103) d6 defect bbross closed 2012-01-20T03:09:41+01:00 2012-02-07T06:02:58+01:00 "abs_diff_pic_num_minus1 and abs_diff_pic_num_minus1 are not included in refernce picture list modification syntax anymore. The following semantics shall be removed from 7.4.3.2. abs_diff_pic_num_minus1 plus 1 specifies the absolute difference between the picture number of the picture being moved to the current index in the list and the picture number prediction value. abs_diff_pic_num_minus1 shall be in the range of 0 to MaxPicNum − 1. The allowed values of abs_diff_pic_num_minus1 are further restricted as specified in subclause 8.2.2.3.1. [Ed. (TW): clarify the following paragraph] long_term_pic_num specifies the long-term picture number of the picture being moved to the current index in the list. When decoding a coded frame, long_term_pic_num shall be equal to a LongTermPicNum assigned to one of the reference frames or complementary reference field pairs marked as ""used for long-term reference"". When decoding a coded field, long_term_pic_num shall be equal to a LongTermPicNum assigned to one of the reference fields marked as ""used for long-term reference"". " eeehey WD5 (G1103) d6 300 Table of hPos and vPos is incorrect Text WD5 (G1103) d6 defect bbross closed 2012-02-01T06:32:48+01:00 2012-02-07T06:31:54+01:00 "Section 8.6.2.1.1 Table 8-58 -- Specification of hPos[2] and vPos[2] according to the type of sample adaptive offset process When sao_type_idx=4, the sampling positions are (1,-1) and (-1,1). hPos and vPos should be: hPos[0] = 1 hPos[1] = -1 vPos[0] = -1 vPos[1] = 1 " yyasugi WD5 (G1103) d8 318 Incorrect taps for 2d sub pixel inter filters Text WD5 (G1103) d8 defect b Bross closed 2012-02-08T20:48:32+01:00 2012-02-09T00:50:16+01:00 "Equations 8-108 etc. Input taps for f,g,k,i,p,q are incorrectr - the 3x3 block of positions that require 2d filtering seem to be transposed. e.g. f should be based on b rather than a terms" rikallen WD5 (G1103) d9 295 mismatch between HM and WD on chroma cbf Text WD5 (G1103) d9 defect bbross closed 2012-01-20T17:26:25+01:00 2012-02-08T21:55:53+01:00 In WD, cb_cbf and cr_cbf syntax elements are signaled differently for intra and inter CU. In SW, they are signaled in the same way for intra and inter CU. Based on the adoption of F606, WD should be modified to match SW. wchien WD5 (G1103) d9 301 Missing description about pcm_sample_loop_filter_disable_flag for SAO Text WD5 (G1103) d9 defect benjamin.bross@… closed 2012-02-01T21:41:59+01:00 2012-02-09T00:36:48+01:00 "The current WD text misses the description about the combination of SAO and pcm_sample_loop_filter_disable_flag. “8.6.2.1.1 Modification process for luma and chroma samples” should be revised according to the attachment in order to synchronize the text and software." kchono WD5 (G1103) d9 310 "missing definition of ""cu_qp_delta_enabled_flag"" in JCTVC-G1103_d9" Text WD5 (G1103) d9 defect bbross closed 2012-02-05T21:55:22+01:00 2012-02-16T03:46:57+01:00 "Benjamin, The variable ""cu_qp_delta_enabled_flag"" in the syntax table has no definition in the latest version of WD, i.e. JCTVC-G1103_d9. Can you fix it? Thanks Best Regards Haoping" haoping WD5 (G1103) d9 1312 "H.265 official spec, 8.5.3.2.8 ""Derivation process for collocated motion vectors"", currPb instead of colPb." Text WD5 (G1103) d9 defect closed 2014-08-13T11:34:43+02:00 2018-01-22T09:06:07+01:00 "Dear experts, I think that there might be a bug in official H265 spec: http://www.itu.int/rec/T-REC-H.265-201304-I T-REC-H.265-201304-I!!PDF-E.pdf Current wording is as follows: ----------------------------------------------------------------------------- Otherwise, the variable availableFlagLXCol is set equal to 1, refPicListCol[ refIdxCol ] is set to be the picture with reference index refIdxCol in the reference picture list listCol of the slice containing prediction block '''currPb''' in the picture colPic, and the following applies: – colPocDiff = DiffPicOrderCnt( colPic, refPicListCol[ refIdxCol ] ) (8-177) ----------------------------------------------------------------------------- In my opinion it should be: ----------------------------------------------------------------------------- Otherwise, the variable availableFlagLXCol is set equal to 1, refPicListCol[ refIdxCol ] is set to be the picture with reference index refIdxCol in the reference picture list listCol of the slice containing prediction block '''colPb''' in the picture colPic, and the following applies: – colPocDiff = DiffPicOrderCnt( colPic, refPicListCol[ refIdxCol ] ) (8-177) ----------------------------------------------------------------------------- Justification: If Reference Picture List (refPicListCol[refIdxCol]) from colPic to be extracted from slice to which currPb belongs (slice which covers corresponding unit) it should be assured that given slice in colPic is not INTRA and it was only assured that slice to which colPb belongs is not INTRA by: If colPb is coded in an intra prediction mode, both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0. Otherwise Reference Picture List could be empty (in INTRA slice). Wlodzimierz Lipert." vlad WD5 (G1103) d9 302 Proofreading issues Text WD5 (G1103) d9 defect bbross closed 2012-02-02T03:40:04+01:00 2012-07-11T12:20:01+02:00 "A few minor proofreading issues I found in WD9. Section 8.4.2.1.6 (p.127): incorrect references: it refers to 8.4.2.1.6, 8.4.2.1.7, and 8.4.2.1.10; it should say 8.4.2.1.7, 8.4.2.1.8, and 8.4.2.1.9 Variable yA1 is defined differently in 8.4.2.1.2 and 8.4.2.1.7 (as yP+nPSH-1 and yP+nPSH-MinPuSize); is there a practical difference between the two definitions? p. 129: ""-"" missing: ""xB1 = xB0 MinPuSize"" p. 129 before (8-135) and p. 130 (8-139): ""RefPicListListB"" should be ""RefPicListLB"" 8.4.2.2.2 (8-95) and (8-96) should be referring to mvCLX instead of mvLX 8.4.3.1 (page 141) if InterTUSplitDirection is equal to 2, yB1 and xB2 are undefined 8.4.3.1 (page 142) and 8.4.3.2 (page 143): ""– The variable log2TrafoWidth1 is set equal to (log2TrafoWidth – 2) * InterTUSplitDirection. – The variable log2TrafoHeight1 is set equal to (log2TrafoHeight - 2) * (1 - InterTUSplitDirection)."" Should be: ""– The variable log2TrafoWidth1 is set equal to log2TrafoWidth – 2 * InterTUSplitDirection. – The variable log2TrafoHeight1 is set equal to log2TrafoHeight - 2 * (1 - InterTUSplitDirection)."" " eugene.kuznetsov WD5 (G1103) d9 307 Clip operation missing in Inverse DST Transform Operation Text WD5 (G1103) d9 defect bbross closed 2012-02-04T21:53:53+01:00 2012-02-09T00:07:40+01:00 The clip operation is missing in the inverse DST operations, similar to inverse DCT. ankur81s WD5 (G1103) d9 309 Typo in weighted prediction Text WD5 (G1103) d9 defect bbross closed 2012-02-05T18:44:16+01:00 2012-02-07T08:37:58+01:00 " 8.4.2.2.3.2 Weighted sample prediction process – Otherwise (C is equal to Cb or Cr for chroma samples, with iCbCr = 0 for Cb, iCbCr = 1 for Cr), logWDc = ChromaLog2WeightDenom + shift1 (8‑209) w0C = ChromaWeightL0[refIdxL0][ iCbCr ] (8‑210) w1C = ChromaWeightL1[refIdxL1][ iCbCr ] (8‑211) o0C = '''ChromaWeightL0'''[refIdxL0][ iCbCr ] * ( 1 << ( BitDepthC – 8 ) ) (8‑212) o1C = ChromaOffsetL1[refIdxL1][ iCbCr ] * ( 1 << ( BitDepthC – 8 ) ) (8‑213) This should be modified as follows: – Otherwise (C is equal to Cb or Cr for chroma samples, with iCbCr = 0 for Cb, iCbCr = 1 for Cr), logWDc = ChromaLog2WeightDenom + shift1 (8‑209) w0C = ChromaWeightL0[refIdxL0][ iCbCr ] (8‑210) w1C = ChromaWeightL1[refIdxL1][ iCbCr ] (8‑211) o0C = '''ChromaOffsetL0'''[refIdxL0][ iCbCr ] * ( 1 << ( BitDepthC – 8 ) ) (8‑212) o1C = ChromaOffsetL1[refIdxL1][ iCbCr ] * ( 1 << ( BitDepthC – 8 ) ) (8‑213)" bbross WD5 (G1103) d9 313 Missing QpBdOffsetC in equations for deriving chroma QPs Text WD5 (G1103) d9 defect bbross closed 2012-02-07T03:35:53+01:00 2012-02-07T19:16:35+01:00 "The derivation of chroma QPs (p.83) is described as follows. The values of QP'Cb and QP'Cr are derived as QP'Cb = Clip3(0, 51, QP'Y + chroma_cb_qp_offset) (7-22) QP'Cr = Clip3(0, 51, QP'Y + chroma_cr_qp_offset) (7-22) QpBdOffsetC should be employed here, for example as follows. QP'Cb = Clip3(0, 51+QpBdOffsetC, QP'Y + chroma_cb_qp_offset) (7-23) QP'Cr = Clip3(0, 51+QpBdOffsetC, QP'Y + chroma_cr_qp_offset) (7-24) " hao WD5 (G1103) d9 319 mismatch between HM and WD on scaling list Text WD5 (G1103) d9 defect bbross closed 2012-02-08T23:46:29+01:00 2012-02-10T10:16:43+01:00 "Default scaling list is defined as 1D array in zigzag scan order. This must be converted into 2D array of ScalingFactor. This conversion from zigzag scan to 2D array is missing in the WD5 d9. Proposed fix is included in the attachment of JCTVC-H0230 together with the description adopted at San Jose." teruhiko WD5 (G1103) d9 320 mismatch between HM and WD on default scaling list for 16x16/32x32 Text WD5 (G1103) d9 defect bbross closed 2012-02-09T01:18:18+01:00 2012-02-09T11:13:47+01:00 " The default value of scaling list for 16x16 and 32x32 are not correct. The correct values are included in JCTVC-G1016-v4.zip" teruhiko WD5 (G1103) d9 321 mismatch between HM and WD on ALF chroma coeff prediction Text WD5 (G1103) d9 defect wjhan closed 2012-02-10T07:43:37+01:00 2012-02-10T10:15:04+01:00 "There are inconsistency between HM and WD on ALF chroma prediction. HM's prediction properly works assuming that ""sum of ALF coeff is equal to or near to 1.0"", so WD should follows HM with the following fixs. (1) fix1 replace cC[ i ] = 255 – sum – alf_coeff_chroma[ i ] (8 468) with cC[ i ] = 256 – sum – alf_coeff_chroma[ i ] (8 468) (2) fix2 replace sum = alf_coeff_chroma[ AlfCodedLengthChroma – 2 ] + sigma_j( alf_coeff_chroma[ j ] << 1 ) (8 469) with j = 0..AlfCodedLengthChroma – 3 with sum = sigma_j ( alf_coeff_chroma[ j ] << 1 ) (8 469) with j = 0..AlfCodedLengthChroma – 2 The corresponding function is TComAdaptiveLoopFilter::predictALFCoeffChroma " Tomohiro Ikai WD5 (G1103) d9 322 editorial: slice header deblocking filter syntax elements Text WD5 (G1103) d9 defect bbross closed 2012-02-10T18:35:28+01:00 2012-02-16T00:02:47+01:00 "The syntax element inherit_dbl_params_from_APS_flag contains upper case letters which does not match the WD style Bold formatting on                beta_offset_div2               tc_offset_div2 is missing." ksuehring v3 (04/2015) 1488 rangeTabLps Text v3 (04/2015) defect closed 2018-04-13T08:06:58+02:00 2018-10-02T07:43:04+02:00 "Table rangeTabLps which was corresponding to Table 9-46 in standard specification, lists all lps range of every state. But, rangeTabLps still exists ""interval inversion"" problem, that is, the subinterval for the MPS may be smaller than the subinterval for the LPS. for example: pStateIdx equals to 1 and qRangeIdx equals to 2, and lps symbol occurs, then m_uiRange equals to 167 which was smaller than 256, so m_uiRange = (m_uiRange << 1) = 334, because of lps symbol, the pStateIdx will translate to 0 and uiLPS = TComCABACTables::sm_aucLPSTable[0][ ( 334 >> 6 ) & 3 ] = 176, so, mps_range = m_uiRange - uiLPS = 334 - 176 = 158, which will cause mps_range < lps_range, that is a bug?" shakingWaves v4 (12/2016) 1489 rangeTabLps error? Text v4 (12/2016) technical change closed 2018-04-13T08:52:45+02:00 2020-06-23T23:09:32+02:00 "Table rangeTabLps which was corresponding to Table 9-46 in standard specification, lists all lps range of every state. But, rangeTabLps still exists ""interval inversion"" problem, that is, the subinterval for the MPS may be smaller than the subinterval for the LPS. for example: pStateIdx equals to 1 and qRangeIdx equals to 2, and lps symbol occurs, then m_uiRange equals to 167 which was smaller than 256, so m_uiRange = (m_uiRange << 1) = 334, because of lps symbol, the pStateIdx will translate to 0 and uiLPS = TComCABACTables::sm_aucLPSTable[0][ ( 334 >> 6 ) & 3 ] = 176, so, mps_range = m_uiRange - uiLPS = 334 - 176 = 158, which will cause mps_range < lps_range, that is a bug?" shakingWaves v4 (12/2016) 1268 Typographical errors (various sections) Text v4 (12/2016) defect closed 2014-04-01T08:28:46+02:00 2018-10-02T07:38:16+02:00 "The following typographical errors have been observed: - partionings - contraints - an an IRAP - by by - invokation - inceasing - curent - mosaicing(?) Errors in variables: - videSeqA - AyCpbRemovalTime - picure_checksum Xref errors: - §E.2.1: after max_bits_per_min_cu_denom, ""is called in subclauses 9.3.4.3.3 and 0""" davidf v4 (12/2016) 1315 Inconsistent variable naming: CpbCnt Text v4 (12/2016) defect closed 2014-08-26T17:31:38+02:00 2018-10-02T07:38:16+02:00 "The variable name CpbCnt loses the ""_minus1"" when being initialized which might be confusing: The variable CpbCnt is set equal to cpb_cnt_minus1[ subLayerId ]. It would be more consistent with our naming rules to initialize it as follows The variable CpbCnt is set equal to cpb_cnt_minus1[ subLayerId ] + 1. And replace the ""<="" in the syntax loops with ""<"". (This applies also for version 2 integrated text JCTVC-R1013_v4)" ksuehring v4 (12/2016) 1398 Typos in the Text Text v4 (12/2016) defect closed 2015-05-29T16:12:24+02:00 2018-10-02T07:38:16+02:00 "In ITU-T H.265 (10/2014) as well as JCTVC-R1013_v6 I found some typos: In F.7.3.2.3.3: ""if( resample_phase_set_prsent_flag[ i ] ) {"" sould be ""if( resample_phase_set_present_flag[ i ] ) {"" In F.7.3.2.3.5: ""idxShiftY = idxY + ( ( i << ( cm_octant_depth − inpDepth ) )"". There is one too many open brackets ""("". In H.8.1.4.2: ... ""where xPb = xB << 4 and xPb = xB << 4, for"" ... I guess the correct version is: ... ""where xPb = xB << 4 and yPb = yB << 4, for"" ... Also in H.8.1.4.2: In steps 4 and 5 the index ""xP"" and ""yP"" are used multiple times. However, these indices were not defined in this context. I guess the correct indices are ""xPb"" and ""yPb""." CFeldmann v4 (12/2016) 1114 Question about log2_max_mv_length_horizontal Text v4 (12/2016) enhancement closed 2013-07-01T16:27:44+02:00 2018-01-22T10:26:53+01:00 "In ""8.5.3.2 Derivation process for motion vector components and reference indices"" there is a note that the resulting values of `mvLX[0]` and `mvLX[1]` will always be in the range `-2^15` to `2^15-1`. However, in ""E.2.1 VUI parameters semantics"" the semantics for log2_max_mv_length_horizontal say that a value of 16 can be sent, meaning that no value of a horizontal motion vector component is outside the range `-2^16` to `2^16-1`, although the default value is 15 if no bitstream restriction parameters are present. This 16 seems odd because: 1. it appears impossible to code a motion vector that would require the value of 16 2. the vertical range is limited to 15 3. it is using a ""bitstream restriction"" to extend the range of motion vectors (all other fields in this structure restrict the allowed range) Question: Should this 16 be a 15, or have I misunderstood something?" peterderivaz v4 (12/2016) 1375 minor fix for the spec Text v4 (12/2016) enhancement closed 2015-02-10T15:58:41+01:00 2020-04-17T15:30:41+02:00 "Table 8 3 – Specification of intraPredModeC when ChromaArrayType is equal to 2 116 Here IntraPredModeC should be, start is assumed to be from the uppercase letter" kolya v4 (12/2016) 1384 orphaned symbol in the spec Text v4 (12/2016) enhancement closed 2015-03-13T17:42:27+01:00 2018-10-02T07:38:16+02:00 "The paragraph just before E.3.2 section says: '''log2_max_mv_length_horizontal''' and '''log2_max_mv_length_vertical''' indicate the maximum absolute value of a decoded horizontal and vertical motion vector component, respectively, in quarter luma sample units, for all pictures in the CVS. A value of n asserts that no value of a motion vector component is outside the range of −2^n^ to 2^n^ − 1, inclusive, in units of quarter luma sample displacement. The value of log2_max_mv_length_horizontal shall be in the range of 0 to 16, inclusive. The value of log2_max_mv_length_vertical shall be in the range of 0 to 15, inclusive. When log2_max_mv_length_horizontal is not present, the values of log2_max_mv_length_horizontal and log2_max_mv_length_vertical is inferred to be equal to 15. What ""n"" here stands for?" kolya v4 (12/2016) 1454 ambiguous formula Text v4 (12/2016) enhancement closed 2016-07-14T16:07:35+02:00 2018-10-03T03:24:29+02:00 "The (8-5) is: pocLt += PicOrderCntVal − DeltaPocMsbCycleLt[ i ] * MaxPicOrderCntLsb − PicOrderCntVal & ( MaxPicOrderCntLsb − 1 ) If reader assumes arithmetic operations are of higher priority than bitwise &, line in C/C++, then formula contains somewhat strange PicOrderCntVal- PicOrderCntVal. " kolya v4 (12/2016) 1403 un-used index in the loop in eq. (F-53) (JCTVC-R1013_v6) Text v4 (12/2016) defect closed 2015-07-20T10:03:58+02:00 2018-10-02T07:38:16+02:00 "In F.7.4.7.1-General slice segment header semantics: The variable ""j"" in the loop is not used. for( i = 0, j = 0; i < NumActiveRefLayerPics; i++ ) (F 53) RefPicLayerId[ i ] = IdDirectRefLayer[ nuh_layer_id ][ inter_layer_pred_layer_idc[ i ] ] " bordesp v5 (02/2018) 1491 duplicate invocation of 9.3.4.3 arithmetic decoding process Text v5 (02/2018) defect closed 2018-06-21T04:22:48+02:00 2025-10-26T18:13:31+01:00 "In 9.3.4.1 in Decoding process flow, 9.3.4.2 and 9.3.4.3 is invoked. However in 9.3.4.2, 9.3.4.3(.x) is also invoked. Thus it seems there's a duplicate invocation: * 9.3.4.1 The parsing of each bin is specified by the following two ordered steps: 1. 9.3.4.2 ( which invokes 9.3.4.3(.x) ) 2. 9.3.4.3 ( which is already invoked in 9.3.4.2 ) Some highlighting example is attached." Tomohiro Ikai v5 (02/2018) 1494 Errnous loop conditions in Table D.2.43 Text v5 (02/2018) defect closed 2018-07-12T16:43:41+02:00 2020-04-17T15:32:10+02:00 "In Table D.2.43 - Motion-constrained tile sets extraction information sets SEI message syntax, the loops around *ps_rbsp_data_byte[ i ][ j ][ k ] syntax elements suffer from an ""off-by-one"" loop condition. ""<"" instead of ""<="" should be used to transmit the number of bytes indicated in *ps_rbsp_data_length[ i ][ j ] syntax elements. " skupin v5 (02/2018) 1498 Typos in the Table 9-43 Text v5 (02/2018) defect closed 2018-09-07T04:26:47+02:00 2025-10-26T18:16:23+01:00 "The Table 9-43 in the current spec(N17728) is: palette_run_suffix cMax = (PrefixOffset << 1) > PaletteMaxRunMinus1 ? (PalletMaxRun − PrefixOffset) : (PrefixOffset − 1) But I think it should be: cMax = (PrefixOffset << 1) > PaletteMaxRunMinus1 ? (PaletteMaxRunMinus1 − PrefixOffset) : (PrefixOffset − 1) " Haruhiko v5 (02/2018) 1499 Equation 8-47 in v5 spec was inadvertently changed from v4 spec Text v5 (02/2018) defect closed 2018-09-18T18:38:44+02:00 2020-04-17T15:31:23+02:00 In the v5 spec, equation 8-47, for dcVal calculation, neighboring predicted pixels are summed up and right shifted by (k-1) bits. It seems to be a mistake caused by formatting. Correct operation should be right shift by (k+1) bits. The same equation in v4 spec is correct. Reference code implementation is correct. RyanLei v5 (02/2018) 1500 typo in equation (8-69),(8-70) Text v5 (02/2018) defect closed 2018-10-03T02:59:46+02:00 2025-10-26T18:17:28+01:00 "The equation (8-69),(8-70) in the current spec(N17728) is: xL = palette_transpose_flag ? x * nSubHeight : x * nSubWidth yL = palette_transpose_flag ? y * nSubWidth : y * nSubHeight But I think it should be: xL = palette_transpose_flag ? **y** * nSubHeight : x * nSubWidth yL = palette_transpose_flag ? **x** * nSubWidth : y * nSubHeight " Haruhiko v5 (02/2018) 1504 Small typos in profile_tier_level syntax in tabular form (7.3.3) Text v5 (02/2018) defect closed 2019-01-08T11:19:20+01:00 2025-10-26T18:20:24+01:00 "In Rec. ITU-T H.265 v5 (02/2018) I found two mistakes in 7.3.3 Profile, tier and level syntax: The first one is right after parsing of the general_frame_only_constraint_flag. In the following if statement, there is a closing bracket after general_profile_compatibility_flag[7] which should probably not be here. The second one is at the end where there is an if clause with various checks for sub_layer_profile_compatibility_flag. However the 2D array of flags is indexed with only one index and missing the sub layer index [i]." CFeldmann v5 (02/2018) 1505 Misleading bitstream requirement related to EOB NAL unit Text v5 (02/2018) defect closed 2020-01-11T10:27:04+01:00 2025-10-26T18:23:14+01:00 "In Section 7.4.2.4.3 ""Order of access units and association to CVSs"" a requirement is expressed related to access units after an end of bitstream NAL unit. ""It is a requirement of bitstream conformance that, when present, the next access unit after an access unit that contains an end of sequence NAL unit or an '''end of bitstream NAL unit''' shall be an IRAP access unit, which may be an IDR access unit, a BLA access unit, or a CRA access unit."" However, in section 7.4.3.7 ""End of bitstream RBSP semantics"" it is said that there are no NAL units (and thus no access units) present after the EOB NAL unit. ""The end of bitstream RBSP indicates that no additional NAL units are present in the bitstream that are subsequent to the end of bitstream RBSP in decoding order."" It seems misleading to impose a requirement on NAL units after the EOB NAL unit and at the same time state that there are no NAL units after the EOB NAL unit. The suggested fix is to remove ""or an end of bitstream NAL unit"" from the bitstream requirement in Section 7.4.2.4.3: ""It is a requirement of bitstream conformance that, when present, the next access unit after an access unit that contains an end of sequence NAL unit shall be an IRAP access unit, which may be an IDR access unit, a BLA access unit, or a CRA access unit.""" jonatan v5 (02/2018) 1507 duplicate row entries for CU QP delta syntax elements in Table 9-48 Text v5 (02/2018) defect closed 2020-04-18T08:20:05+02:00 2025-10-26T18:06:31+01:00 "In the Table 9-48 (Assignment of ctxInc to syntax elements with context coded bins), there appears to be duplicate row entries for: cu_qp_delta_abs. cu_qp_delta_sign_flag cu_chroma_qp_offset_flag cu_chroma_qp_offset_idx [ Cue ""The Dirty fork"" Monty Python sketch :-) ]" chadfogg v5 (02/2018) 1515 The possible editorial changes related WPP Text v5 (02/2018) defect Yue Yu closed 2021-11-17T00:51:49+01:00 2021-11-17T19:35:56+01:00 In the current HEVC specification(11/2019), some places (9.3.1 and 9.3.2.1) use TableStateIdxWpp, TableMpsValWpp, TableStatCoeffWpp, PredictorPaletteSizeWpp and PredictorPaletteEntriesWpp, but some places (9.3.2.4 and 9.3.2.5) use tableStateSync, tableMPSSync, tableStatCoeffSync, PredictorPaletteSizeWpp and PredictorPaletteEntriesWpp. Suggest to correct this inconsistency. yyu2021 v5 (02/2018) 1522 Offset issue in clause 8.5.4.3 Text v5 (02/2018) defect closed 2024-05-02T02:13:30+02:00 2025-10-26T17:55:27+01:00 "(filed on behalf of Min Woo) In section 8.5.4.3, Equation (8-279) appears to have an issue. resSamples is a block level array but picture-level offsets (xCb, yCb) are applied when addressing samples in this array. The equation should instead be: 6. The (nCbS)x(nCbS) residual sample array of the current coding block resSamples is modified as follows, for i = 0..nTbS − 1, j = 0..nTbS − 1: resSamples[ xB0 / SubWidthC + i, yBN / SubHeightC + j ] = transformBlock[ i, j ] (8 279) " crosewarne 1404 Input samples to INTRA_PLANAR (JCTVC_R1013_v6) Text defect closed 2015-07-20T11:00:31+02:00 2018-01-22T06:30:31+01:00 "In 8.4.4.2.4 - Specification of intra prediction mode INTRA_PLANAR: the neighbouring samples p[ x ][ y ], with x = −1, y = −1..nTbS * 2 − 1 and x = 0..nTbS * 2 − 1, y = −1 correct values are : x=-1, y=-1..nTbS and x=-1..nTbS, y=-1." bordesp 1439 IRAP constraint for Main 4:4:4 Intra profile Text defect closed 2016-02-15T11:12:41+01:00 2018-01-22T06:32:45+01:00 "The spec says (e.g. JVCTV-V1005-v1), in A.3.5, – In bitstreams conforming to the Main Intra, Main 10 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 10 Intra, Main 4:4:4 12 Intra, or Main 4:4:4 16 Intra profiles, all pictures with nuh_layer_id equal to 0 shall be IRAP pictures and the output order indicated in the bitstream among these pictures shall be the same as the decoding order. However, ""Main 4:4:4 Intra"" is not listed. I think this is a typo of the spec text and should be fixed as below. – In bitstreams conforming to the Main Intra, Main 10 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, '''Main 4:4:4 Intra''', Main 4:4:4 10 Intra, Main 4:4:4 12 Intra, or Main 4:4:4 16 Intra profiles, all pictures with nuh_layer_id equal to 0 shall be IRAP pictures and the output order indicated in the bitstream among these pictures shall be the same as the decoding order. As a background, the issue is found on checking GENERAL_8b_444_RExt_Sony_1 which (not intentionally) includes TRAIL NAL in the Intra profile bitstream. If the text fix is agreed, the bitstream will also be revised. " o.nakagami 1455 Typo on transformSkip & rotateCoeffs Text defect closed 2016-07-25T10:21:24+02:00 2018-01-22T06:35:49+01:00 "JCTVC-W1005-v4 says, r[ x ][ y ] = ( rotateCoeffs ? d[ nTbS − x −1 ][ nTbS − y − 1 ] : d[ x ][ y ] << tsShift ) (8‑300) but it should be, r[ x ][ y ] = ( rotateCoeffs ? d[ nTbS − x −1 ][ nTbS − y − 1 ] : d[ x ][ y ] ''' ) << tsShift ''' (8‑300) because ""<<"" operation was applied before ""x?:y:z"" operation according to Table 5-1 (Operation precedence). " o.nakagami 1520 Some smaller errors in the multiview spec Text defect closed 2024-02-29T17:07:24+01:00 2025-10-28T17:43:02+01:00 "It is not specified with how many bits the symbol sps_palette_predictor_initializer[comp][i] is coded. It is mentioned that it must be in the range 0 to (1 << BitDepthY/C) − 1 so I deduced that it should be using BitDepthY/C bits and this was confirmed by the reference software. However, this should be mentioned explicitly as for the other symbols with u(v) coding. In F.7.4.3.1.1, the variable maxSlMinus1 has a typo. The L is sometimes uppercase sometimes lower case. In F.7.4.3.1.1, equation F-12. There is a `}` missing at the end of the equation" CFeldmann 1524 Typos in Annexes C and D Text defect new 2026-06-30T08:44:13+02:00 2026-06-30T08:44:13+02:00 "Typos were found in ITU-T H.265 (V11) (01/2026), as follows: D.3.2: ""acces"" C.1: ""assocciated"" " crosewarne 1448 offset_len_minus1 range Text enhancement closed 2016-04-08T20:34:28+02:00 2018-01-22T06:34:03+01:00 "The spec says that valid range for offset_len_minus1 is [0, 31]. At the same time, offset_len_minus1=0 means that there is a slice segment of 1 byte size (entry_point_offset_minus1 == 0). But this is not possible coz every slice segment should contain at least 9 bits according to the clause 9.3.2.6. Thus the valid range for offset_len_minus1 should be described as [1, 31] and valid range for entry_point_offset_minus1 is [1, 2^32 - 1]. (on behalf of pavel.evsikov@intel.com)" kolya 1451 not clear spelling Text technical change closed 2016-05-24T17:23:37+02:00 2018-01-22T10:53:59+01:00 "In the spec, there is: pcm_enabled_flag equal to 0 specifies that PCM data are not present in the CVS. NOTE 4 – When MinCbLog2SizeY is equal to 6, PCM data are not present in the CVS even when pcm_enabled_flag is equal to 1. The maximum size of coding block with pcm_enabled_flag equal to 1 is restricted to be less than or equal to Min( CtbLog2SizeY, 5 ). Encoders are encouraged to use an appropriate combination of log2_min_luma_coding_block_size_minus3, log2_min_pcm_luma_coding_block_size_minus3, and log2_diff_max_min_pcm_luma_coding_block_size values when sending PCM data in the CVS. It is not clear what PCM data are assumed not to be in the stream: only PCM samples, or related syntax like pcm_sample_bit_depth_luma_minus1 etc." kolya 1412 Typo in H.8.1.4 Derivation process for inter-layer reference pictures (in R1013_v6 and U1005_v2) Text defect closed 2015-09-08T06:02:20+02:00 2015-10-20T10:03:13+02:00 "In H.8.1.4 Derivation process for inter-layer reference pictures, cmPic is used as "" the picture sample resampling process as specified in clause H.8.1.4.1 is invoked with the picture sample arrays, cmPicSampleL, cmPicSampleCb and cmPicSampleCr, of the colour mapped direct reference layer picture '''cmPic''' as inputs, and with the resampled picture sample arrays, rsPicSampleL, rsPicSampleCb and rsPicSampleCr of the inter-layer reference picture ilRefPic as outputs."" But the cmPic seems not defined. On the other hand, cmRefPic is derived but not used. Maybe replacing cmPic with cmRefPic resolves this issue (or replacing cmRefPic with cmPic). In addition, ""If equalPictureSizeAndOffsetFlag is equal to 1, BitDepthRefLayerY is equal to BitDepthCurrY, BitDepthRefLayerC is equal to BitDepthCurrC, SubWidthRefLayerC is equal to SubWidthCurrC and SubHeightRefLayerC is equal to SubHeightCurrC, the following applies: "", how to generate ilRefPic is not so clear althogh rsPicSampleL, rsPicSampleCb and rsPicSampleCr are set (these parameters should be about ilRefPic). " Tomohiro Ikai