id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 645,Bit count for slice header with RPS_COUNTER,adarsh,,"This is with respect to the HM-7.0-dev-AHG13 branch. The bits used by the RPS-related parameters int the slice header are counted using the m_bitsForSliceHeader and finally printed in TAppDecTop.cpp. Before printing, the actual number of bits is calculated by ''int shbits = (m_cTDecTop.getPPS()->getBitsForSliceHeader()+2)/2; //All slice headers except for the first intra picture are counted twice. The first intra costs 2 bits.'' The comment refers to the issue with the decoder software that the slice header is parsed twice; but this is true only for the slice header of the first slice of the picture. The slice headers of the rest of the slices are parsed only once. This is described in the comment in TAppDecTop.cpp ''/* location serves to work around a design fault in the decoder, whereby the process of reading a new slice that is the first slice of a new frame requires the TDecTop::decode() method to be called again with the same nal unit. */'' When the final bit-count is divided by two (in the above equation), it implicitly assumes that there is only one slice per each picture or all slice headers are parsed twice. This would be erroneous for cases where there are more than one slice, which is often the case when the MTU-size matching mode is enabled in the common conditions described in I0608. A solution to this problem would be to check whether the current parse of the slice header is indeed the first parse (which happens only for the first slice), and only count the bits then. The attached patch (w.r.t. r2613) provides a possible solution.",defect,closed,minor,,HM,HM-7.0,fixed,,fbossen ksuehring davidf jct-vc@…