AV1 Metadata sample group for T.35 metadata

[podborski]

In the spec we recommend to use the AV1 Metadata Sample Group av1M if metadata OBUs are carried in samples. The 32bit grouping_type_parameter of 'sbgp' is used as:

{
   unsigned int (8) metadata_type;
   unsigned int (24) metadata_specific_parameters;
}

where metadata_specific_parameters is only defined when metadata_type is set to METADATA_TYPE_ITUT_T35 in which case its value SHALL be set to the first 24 bits of the metadata_itut_t35 structure.

However, first 24 bits of the T.35 data are unfortunatelly not enough to provide reasonable signaling for grouping samples with T.35 messages.

The T.35 message consists of 3 parts:

• country code (1 or 2 bytes)
• terminal provider code (size depends on what each National Body decides, for US and Canada 2 bytes are used)
• terminal provider oriented code (size depends on what the terminal provider decides internally, usually this will contain a header identifying the type of metadata and the actual payload for it).

So, currently, even if we take for example T.35 messages defined by a company from US or Canada, we will consume all 3 bytes of metadata_specific_parameters to signal the country and the terminal provider. If the terminal provider defines multiple T.35 messages with different terminal provider oriented codes, it will be not possible to group the samples accordingly.

[podborski]

Maybe one more thing to discuss here would be the usage of the grouping_type_parameter (or even the entire av1M) in general. It kind of looks odd that a single 4CC is used to identify all kinds of different metadata. And since there seems to be no value in specifying the metadata_specific_parameters should we consider defining separate sample group entries for each type of metadata maybe?

[cconcolato]

The group agrees that the current way to identify sample with T35 metadata is not sufficient. We will monitor the progress of generic T35 carriage in ISOBMFF. We may consider to deprecate the entire av1M sample group unless use cases for non-T35 carriage are indicated.

[cconcolato]

MPEG has technologies under considerations for this use case: https://www.mpeg.org/wp-content/uploads/mpeg_meetings/139_OnLine/w21727.zip

[cconcolato]

MPEG is now moving forward with a new Working Draft/Amendment of ISOBMFF to add a sample group for T.35.

[cconcolato]

We could add a note:

The current design of the sample group does not permit identifying the exact type of ITU-T T.35 message and inspecting the payload of the message may be necessary.