Opened 3 months ago

Closed 3 months ago

#1234 closed defect (fixed)

Spec/SW mismatch: long start codes (B.2.2)

Reported by: fbossen Owned by:
Priority: minor Milestone: VTM-10.0
Component: VTM Version: VTM-9.3
Keywords: Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…

Description

The spec appears to mandate long start codes for APS NAL units:

When one or more of the following conditions are true, the zero_byte syntax element shall be present:
– The nal_unit_type within the nal_unit( ) syntax structure is equal to DCI_NUT, VPS_NUT, SPS_NUT, PPS_NUT, PREFIX_APS_NUT, or SUFFIX_APS_NUT.
– The byte stream NAL unit syntax structure contains the first NAL unit of an AU in decoding order, as specified in subclause 7.4.2.4.4.

However, the software doesn't do that:

    if (it == au.begin() || nalu.m_nalUnitType == NAL_UNIT_DCI || nalu.m_nalUnitType == NAL_UNIT_SPS || nalu.m_nalUnitType == NAL_UNIT_VPS || nalu.m_nalUnitType == NAL_UNIT_PPS)

    {
      /* From AVC, When any of the following conditions are fulfilled, the
       * zero_byte syntax element shall be present:
       *  - the nal_unit_type within the nal_unit() is equal to 7 (sequence
       *    parameter set) or 8 (picture parameter set),
       *  - the byte stream NAL unit syntax structure contains the first NAL
       *    unit of an access unit in decoding order, as specified by subclause
       *    7.4.1.2.3.
       */
      out.write(reinterpret_cast<const char*>(start_code_prefix), 4);
      size += 4;
    }
    else
    {
      out.write(reinterpret_cast<const char*>(start_code_prefix+1), 3);
      size += 3;
    }

I don't know which one is correct. (Except for the comment in the software which definitely looks outdated...)

Change history (4)

comment:1 Changed 3 months ago by yk

For the ticket itself, I think the text is correct, as the intention has been that all parameter sets NAL units and other parameter-set-like NAL units are required to have the zero_byte.

However, there is a related issue: We have all the parameter sets and DCI in the list of NUTs that are required to have the zero_byte, but we don’t have the OPI in the list, while OPI is pretty much treated similarly as DCI in all other contexts. It seems to be an overlook.

Should we add OPI to the list at this very late stage?

comment:2 Changed 3 months ago by fbossen

  • Component changed from spec to VTM
  • Version changed from VVC D10 vD to VTM-9.3

Thank you for looking into this. I tracked down the decision to JVET-O0154. It was incorrectly marked as "already in SW" in the SW integration sheet, hence the mismatch. I am changing this to a VTM issue.

comment:3 Changed 3 months ago by ksuehring

comment:4 Changed 3 months ago by fbossen

  • Milestone set to VTM-10.0
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.