AOMediaCodec / av1-spec

AV1 Bitstream & Decoding Process Specification
https://aomedia.org/
Other
335 stars 69 forks source link

Can the operating_point_idc array contain both 0 and nonzero values? #312

Open wantehchang opened 4 years ago

wantehchang commented 4 years ago

What version / commit were you testing with? (git describe can produce this info.)

AV1 Bitstream & Decoding Process Specification commit 07bf57d1c8b072f34fdc60f3194ef1b8c1cc8cdb

Note: This issue is also in Version 1.0.0 with Errata 1. Since the requirements on obu_extension_flag were updated after Version 1.0.0 with Errata 1 was released, I will refer to the current HEAD version in this bug report.

Section 6.4.1 (General sequence header OBU semantics) of the spec has two requirements on obu_extension_flag:

If operating_point_idc[ op ] is not equal to 0 for any value of op from 0 to operating_points_cnt_minus_1, it is a requirement of bitstream conformance that obu_extension_flag is equal to 1 for all layer-specific OBUs in the coded video sequence.

and

It is a requirement of bitstream conformance that if OperatingPointIdc is equal to 0, then obu_extension_flag is equal to 0 for all OBUs that follow this sequence header until the next sequence header.

operating_point_idc and OperatingPointIdc are related by the following equations in the sequence_header_obu() function in Section 5.5.1 (General sequence header OBU syntax):

operatingPoint = choose_operating_point( )
OperatingPointIdc = operating_point_idc[ operatingPoint ]

If the operating_point_idc array contains both 0 and nonzero values, then we can set OperatingPointIdc to 0 (by having choose_operating_point( ) choose the 0 value in the operating_point_idc array) and the two requirements will require obu_extension_flag be equal to both 0 and 1 for all layer-specific OBUs in the coded video sequence, which is absurd.

One way out of this contradiction is to disallow the operating_point_idc array to contain both 0 and nonzero values. I suspect this is the intention of the spec, but the spec does not impose this constraint. The only constraint on the values in the operating_point_idc array is that all values in operating_point_idc must be different from each other (in Section 6.4.1. General sequence header OBU semantics):

It is a requirement of bitstream conformance that operating_point_idc[ i ] is not equal to operating_point_idc[ j ] for j = 0..(i - 1).

Note: This constraint means it is not allowed for two operating points to have the same value of operating_point_idc.

Should we impose the constraint that the operating_point_idc array must contain either a single 0 value (i.e., operating_points_cnt_minus_1 = 0 and operating_point_idc[ 0 ] = 0) or all nonzero values?

peterderivaz commented 4 years ago

The guidelines when writing the spec was to only include necessary constraints (with the rationale that this avoids confusing the reader when they read a constraint that is already implied by other constraints). If there is something helpful that can be deduced, then instead a Note is used (e.g. "Note: This constraint means it is not allowed for two operating points to have the same value of operating_point_idc.")

As you have pointed out, the restrictions in the current spec ensure that the suggested constraint is already satisfied because it is impossible to create a stream that has a mixture of zero and non-zero values.

However, if people agree this is confusing, then I suggest a Note is added, e.g.

Note: This constraint means it is not allowed for the operating_point_idc array to contain a mixture of zero and non-zero values.

StephenBotzko commented 4 years ago

I agree that this could be confusing. The note is a better approach than creating a new constraint that is redundant.