Opened 8 months ago

Closed 2 months ago

#1637 closed defect (fixed)

The wording of H.266 B.3 seems to require byte streams to start with at least three zeros

Reported by: dreifachstein Owned by:
Priority: minor Milestone:
Component: spec Version:
Keywords: Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…

Description

Quoting B.2:

... is such that the next four bytes in the bitstream form the four-byte sequence 0x00000001.

Yet RAP_B_1.bit starts with only two zeros.

The same discrepancies exist between H.264/5 and conformance bitstreams.

Attachments (1)

RAP_B_1_added_one_byte.bit (20.9 KB) - added by iole_moccagatta 3 months ago.

Download all attachments as: .zip

Change history (5)

comment:1 Changed 4 months ago by yk

Thanks! I just had a discussion with Gary on this.

From the syntax of the byte_stream_nal_unit( ) syntax structure, it indeed seems that a bitstream in the byte stream format could start with either 0x000001 (at least two zero-valued bytes) or 0x00000001 (at least three zero-valued bytes).

However, in the semantics of zero_byte, there is the following constraint:

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 VPS_NUT, SPS_NUT or PPS_NUT.
– The byte stream NAL unit syntax structure contains the first NAL unit of an access unit in decoding order, as specified in clause 7.4.2.4.4.

That constraint requires that there are at least three zero-valued bytes at the start of an access unit and a VPS/SPS/PPS NAL unit. Therefore, consequently, it is required that there are at least three zero-valued bytes at the start of a bitstream, which is always a start of an access unit. The reason of having this constraint was for byte-alignment recovery in some system environments wherein a decoder may not always have byte alignment with a bitstream (see the informative clause B.4).

Therefore, the text is OK, while the conformance bitstream is not a conforming bitstream.

To those who are the editors of the VVC conformance spec, please take note on this and take action. I will keep this ticket open for a while, and will close it after an action is taken.

comment:2 Changed 4 months ago by iole_moccagatta

Thanks for reporting this problem for the VVC conformance stream RAP_B_1.bit.

Re:
The same discrepancies exist between H.264/5 and conformance bitstreams.
Are you aware of H.264/5 conformance streams with the same issue ?

Changed 3 months ago by iole_moccagatta

comment:3 Changed 3 months ago by iole_moccagatta

I edited RAP_B_1.bit by adding one zero-valued byte at the beginning of the file. The original and edited have identical decoded output. I attached the edited.

Let me know if there are additional conformance streams that have a similar problem. If not, we can probably close this ticket.


comment:4 Changed 2 months ago by yk

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