peterderivaz
commented
10 months ago Looks reasonable to me.
I am not sure if any of the important people get notified of issues here, so you will probably have to mention it at the working group to get the change adopted. If there is reluctance to change the content, then at least a note could be added to prevent others from having to debug the same issue again!
The specified uvlc parsing process does not match that used by the libaom reference implementation [1]. The specification encodes 2^32-1 as at least thirty-two zero bits followed by a one, while libaom uses exactly thirty-two zero bits without a one. Other implementations also do not match the specification here ([2] matches the libaom behaviour, [3] raises an error if it sees this case).
The difference is never encountered in conforming streams because the one syntax element using the uvlc parsing process (
num_ticks_per_picture_minus_1) is not allowed to take the maximum value of 2^32-1. Given that this area is therefore not covered for conformance purposes, it seems easier to update the text of the specification to match the existing implementations than to do the reverse.[1] https://aomedia.googlesource.com/aom/+/refs/heads/main/aom_dsp/bitreader_buffer.c, line 63.
[2] https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Source/Lib/Decoder/Codec/EbDecBitstream.c?ref_type=heads#L68
[3] https://chromium.googlesource.com/codecs/libgav1/+/refs/heads/main/src/utils/raw_bit_reader.cc, line 161.