AV1 spec implies the sequence header may require an extension header

[daviesthomasj]

In section 6.4.1 on the general semantics of the sequence header OBU, the specification says:

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

This may be taken to mean that the SH itself has the extension flag set and therefore has an extension header. But the SH is shared between all layers and so does not need an extension header.

Note that the Vega Analyzer makes this interpretation, and will flag an error. libaom does not produce an extension header for the SH obu[Edit: and neither aomdec or dav1d will decode if one is added].

[daviesthomasj]

I believe the intent was to imply that obu_extension_flag is 1 for all frame / frame header / tile group OBUs. However this could easily be specified directly for the relevant OBUs and in fact 6.4.1 should state that obu_extension_flag is 0 for this OBU.

[peterderivaz]

Yes, I think you are quite right. I think your understanding of the intent is correct (sequence headers must have extension flag equal to 0) and that the text should be adjusted as you say. My understanding is that edits to AV1 are controlled by the AOM Codec Working Group, but I think their attention is primarily on AV2 at the moment so it may be a while before anything happens.

[wantehchang]

Hi @daviesthomasj,

Thank you for reporting the issue. This is a long-standing issue. That requirement is ambiguous and looks like an incomplete sentence. There was an earlier attempt to clarify it:

#281

86fb0ac

The proposed change to the AV1 spec (committed to the repository on Sep 9, 2019 but not yet published) clarified this by introducing the notion of "layer-specific OBUs" and changing that requirement to the following (I added the boldface emphasis to show the change):

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.

Because that requirement is ambiguous, I am ignoring it in libaom. Instead, libaom follows a similar requirement in Section 7.5. Ordering of OBUs:

If a coded video sequence contains at least one enhancement layer (OBUs with spatial_id greater than 0 or temporal_id greater than 0) then all frame headers and tile group OBUs associated with base (spatial_id equals 0 and temporal_id equals 0) and enhancement layer (spatial_id greater than 0 or temporal_id greater than 0) data must include the OBU extension header.

Note that this requirement is not marked as a "requirement of bitstream conformance", so I am not sure if it is considered a normative requirement.

[wantehchang]

Here are the two libaom commits of mine related to this issue:
https://aomedia-review.googlesource.com/c/aom/+/139587
https://aomedia-review.googlesource.com/c/aom/+/191103

[daviesthomasj]

Thank you for the context @wantehchang - I wondered if it was part of those issues but I could not track the link down

As of now it seems that adding an OBU extension header to the SH is accepted by aomdec and dav1d

[wantehchang]

Thanks for the update on aomdec and dav1d. I was surprised to read your original report that "neither aomdec or dav1d will decode if one is added".

In any case, we should not add an OBU extension header to the sequence header OBU.

[daviesthomasj]

I agree that is technically the right answer, but it is being flagged by at least one analyzer unfortunately

[wantehchang]

If the AOM Codec Working Group doesn't have time to update the AV1 spec, I wonder if it can issue an official interpretation of that ambiguous requirement as a stopgap measure.

@agrange @andrey-norkin What do you think?

@daviesthomasj I'd be happy to talk to the Vega Analyzer vendor about this issue. I am wondering if you could help put me in touch with them or report this issue in their issue tracker. Thanks!