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

[fbossen]

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...)

[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?

[fbossen]

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.

[ksuehring]

I submitted

​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/1788

to align the software with the spec.