Consider porting proposed DVB text to AOM spec.

[cconcolato]

During the initial development of this specification, it was expected that some text would land in a DVB specification. It is looking unlikely, and we should consider if some that text should be moved back into the AOM spec: https://docs.google.com/document/d/1wYVVqEiPhULxpoKU6h2Y5Naq1JL-pcW6vvrpFe7pjps/edit?tab=t.0

[agrange]

DVB is sadly no longer relevant for us, so +1 to moving back to an AOM standalone binding spec. We should review whether some of the changes we put in specifically for the DVB still make sense. Adrian

…

On Mon, Mar 24, 2025 at 10:26 AM Cyril Concolato ***@***.***> wrote: During the initial development of this specification, it was expected that some text would land in a DVB specification. It is looking unlikely, and we should consider if some that text should be moved back into the AOM spec: https://docs.google.com/document/d/1wYVVqEiPhULxpoKU6h2Y5Naq1JL-pcW6vvrpFe7pjps/edit?tab=t.0 — Reply to this email directly, view it on GitHub <#46>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCQPU3CAQYB5E2B5P2DWT2WA53RAVCNFSM6AAAAABZVQG3PSVHI2DSMVQWIX3LMV43ASLTON2WKOZSHE2DGOJWGE3DSNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: cconcolato]*cconcolato* created an issue (AOMediaCodec/av1-mpeg2-ts#46) <#46> During the initial development of this specification, it was expected that some text would land in a DVB specification. It is looking unlikely, and we should consider if some that text should be moved back into the AOM spec: https://docs.google.com/document/d/1wYVVqEiPhULxpoKU6h2Y5Naq1JL-pcW6vvrpFe7pjps/edit?tab=t.0 — Reply to this email directly, view it on GitHub <#46>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCQPU3CAQYB5E2B5P2DWT2WA53RAVCNFSM6AAAAABZVQG3PSVHI2DSMVQWIX3LMV43ASLTON2WKOZSHE2DGOJWGE3DSNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[joaoserra]

Can you guys add a bit more context? Why isn't DVB interested in this?

[cconcolato]

Our analysis of the DVB document and of what needs to be ported into the AV1 spec and how is the following:
Here are the sections of the DVB document and the proposed actions in the AV1 spec:
2.1 is the list of normative references - no port needed
4.1.5.1 discusses the use of the random_access_indicator. We propose to port the text into the section 3.4. This is related to issue #16
4.1.5.2 similarly, it discusses the use of elementary_stream_priority_indicator, we propose to add text to 3.4. This is related to issue #16
4.1.6.9 discusses data_alignment_indicator. It is already covered in 3.4. No action necessary.
4.1.6.10 discusses PTS/DTS. This is covered in 3.5. The only needed change would be to change “are” to “shall”.
4.1.8.33 discusses AV1_video_descriptor. It is already covered in section 2.2. No action necessary.

5.15 is generally related to DVB profiles. It contains encoding and decoding requirements. Should we have both in the AV1 MPEG-2 TS spec?
5.15.1.2 discusses support for private metadata like SEI. This corresponds to Metadata OBUs in AV1. The current AV1-MPEG-2 TS spec does not say anything about that. Explicit support could be added.

5.15.1.3 does not seem relevant. There is no equivalent of VPS in AV1.

5.15.1.4 discusses:

• the use of HRD parameters. "shall set sps_ptl_dpb_hrd_params_present_flag equal to 1", "shall contain a profile_tier_level syntax structure".
• the frequency of changes of profiles/levels "shall be greater than or equal to one second".
  Should we have the same requirements?

We should add text about reduced_still_picture_header and still_picture being set to 0?

5.15.1.5 discusses a concept that does not exist in AV1. We can ignore.
5.15.1.6 discusses active PPS. This concept does not exist in AV1. We can ignore.
5.15.1.7 requires support for specific NAL unit types (OPI and GDR). We can simply say the support for all AV1 spec is required.
5.15.1.8 is about VUI, more specifically
5.15.1.8.1 is about requiring VUI, in particular interlaced (not relevant), aspect ratio, color config (CICP, range, ...). These elements are not optional in AV1. So no need to add more text.
5.15.1.8.2 is not relevant (mandating progressive scan)
5.15.1.8.3 is about mandating the 16:9 aspect ratio. I'm not sure we need to mandate it. We could use a "should" or "can" but not a hard requirement.
5.15.1.8.4 is about over_scan. I'm not sure the feature exists in AV1. I would not port that section.
5.15.1.8.5/5.15.1.8.6/5.15.1.8.7 are about about CICP values (and range and chroma location). I don't think we need to say anything. These fields are not optional in AV1.

5.15.1.9 is about the use of SEI. This is related to the above recommendation. We should have text saying Metadata OBUs are supported and where.

5.15.1.10 is again about Random Access Point, which we cover in 3.4. The only additional text seems to be about

• "improving channel change" : "it is recommended that the PTS of a RAP be less than or equal to [DTS(rap) + 0,67 seconds]". We could add that as a should?
• frequency of RAP: "The encoder shall place RAPs at least once every 2 s. Where rapid channel change times are important or for applications such as PVR it may be appropriate for RAPs to occur more frequently, such as every 1 second." We probably use that text, maybe with "should"

5.15.1.11 is about

• mandating special values of matrix coefficients and transfer characteristics or bit depth. I don't think we want to go this far.
• It also explicitly lists support for MDCV and CCLI metadata. We should cover that in the section about metadata OBUs.
• It then makes explicit support for Dynamic HDR metadata. We should just have a generic sentence saying metadata OBUs may carry HDR dynamic metadata.

5.15.2, 5.15.3, 5.15.4 and 5.15.5 are about specific profiles. I don't think we should have these profiles yet.

Feedback welcome on this analysis. We will prepare several Pull Requests to cover the above.