Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wantehchang opened this issue Aug 25, 2020 · 2 comments
Open

Comments

@wantehchang
Copy link
Collaborator

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

AV1 Bitstream & Decoding Process Specification
commit 07bf57d

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
Copy link
Collaborator

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants