Opened 5 years ago
Closed 5 years ago
#591 closed defect (fixed)
Typos and minor issues in HRD related text
Reported by: | vdrugeon | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | spec | Version: | |
Keywords: | Cc: | ksuehring, bbross, XiangLi, fbossen, jvet@… |
Description
- In 7.4.5.2 Sub-layer HRD parameters semantics: "For any j greater than 0 and any particular value of i, cpb_size_value_minus1[ i ][ j ] shall be less than or equal to cpb_size_value_minus1[ i − 1 ][ j ]". At first sight, it seems that the following makes more sense: "For any j greater than 0 and any particular value of i, cpb_size_value_minus1[ i ][ j ] shall be less than or equal to cpb_size_value_minus1[ i ][ j − 1 ]" (same condition as for bit_rate_value_minus1)
- In C.2.2 and C.2.3, the variables DecodingUnitHrdFlag and decodingUnitParamsFlag seem to be mixed in conditions: "If the value of decodingUnitParamsFlag is equal to 1, ... / Otherwise (DecodingUnitHrdFlag is equal to 0), ...". Are they intended to be the same? If yes, are two variables really needed?
- The variable decodingUnitParamsFlag is used at the beginning of C.2.3, but never derived.
- In the equations for FinalArrivalTime and DuFinalArrivalTime, BitRate is missing the first index [Htid].
- InitCpbRemovalDelay is missing the first index [Htid] in several places in C.2.3 and C.4.
- In C.2.3: "If DecodingUnitHrdFlag is equal to 1, the removal time of access unit n from the CPB is specified as follows" is followed by "Otherwise (DecodingUnitHrdFlag is equal to 1), the removal time of decoding unit m from the CPB is specified as follows". This is contradictory. Should it be "If DecodingUnitHrdFlag is equal to 0," in the first sentence instead?
- In C.2.3, the variables for the final CPB arrival time of access unit n FinalArrivalTime, the nominal CPB removal time of access unit n NominalRemovalTime and the CPB removal time of access unit n CpbRemovalTime sometimes have a name starting with "Au" and sometimes not, which makes the text very confusing.
- In the syntax of sub_layer_hrd_parameters: "for( j = 0; j <= hrd_cpb_cnt_minus1[ subLayerId ]; j++ ) {". The variable hrd_cpb_cnt_minus1 does not have an index on the sub layer ID anymore. Same problem in A.4.1 and A.4.2, whereby in addition the "hrd_" part is missing in the name of the variable.
- The variables nal_initial_cpb_removal_delay and vcl_initial_cpb_removal_delay are missing an index in several places in C.1 and C.2.2.
- In D.3.8 Subpicture level information SEI message semantics, the variables SubPicCbpSizeVcl, SubPicCbpSizeNal, SubPicSetCbpSizeVcl and SubPicSetCbpSizeNal are defined and used. Should these variables be named SubPicCpbSizeVcl, SubPicCpbSizeNal, SubPicSetCpbSizeVcl and SubPicSetCpbSizeNal instead (i.e. Cpb for Coded Picture Buffer instead of Cbp for Coded Buffer Picture)? Another instance of CBP instead of CPB can also be found in the semantics of bp_max_sub_layers_minus1.
Change history (3)
comment:1 Changed 5 years ago by vdrugeon
- In Annex E, in the semantics of field_seq_flag, I believe that the rules for the presence of the picture timing SEI message do not apply anymore, since the field related information from the picture timing SEI message has been moved to the frame field information SEI message. So I believe that the corresponding parts in the semantics can be removed: "field_seq_flag equal to 1 indicates that the CVS conveys pictures that represent fields, and specifies that a PT SEI message shall be present in every AU of the current CVS. field_seq_flag equal to 0 indicates that the CVS conveys pictures that represent frames and that a PT SEI message may or may not be present in any AU of the current CVS. "
comment:2 Changed 5 years ago by yk
Items 1/4/5/6/8/9/10/11: Good catches. Fixed in JVET-P2001-v10.
Item 2: There is a need of both DecodingUnitHrdFlag and decodingUnitParamsFlag, as in HEVC. This relates to allowing skipping the DU-based HRD parameters and operating the HRD at the AU-level even when DU based HRD parameters are present. However, decodingUnitParamsFlag should not be used in clause C.2.3. I added the following editors' note as a reminder that some fix is needed to clearly specify when to use the alternative set of HRD parameters: [Ed. (VD/YK): Something is wrong here, at least for the mixed use of decodingUnitParamsFlag, which is but should not be a local variable, and DecodingUnitHrdFlag. With the introduction of the alternative HRD parameters for CRA/RASL and DRAP cases, the condition of when to use the alternative set of HRD parameters definitely needs to be updated.]
Item 3: See item 2 above.
Item 7: Some major editorial clean-up regarding this aspect is needed.
comment:3 Changed 5 years ago by yk
- Resolution set to fixed
- Status changed from new to closed