Proposal for an alternative descriptor mechanism

[tbiat]

The current situation :

• We define an AV1 Video Descriptor relying on private data approach. But we don't have a registered private_data_specifier yet.
• We expect DVB to give us an extended descriptor when AV1 will be approved.

The problem is that we'll have to revisit the spec later on when DVB will decide on AV1, but at the meantime DVB needs a spec ready to decide (chicken&egg).

If we want to avoid this situation there are two options : -1) Use similar approach as AVS3 ==> Pick a descriptor tag value in the user-defined range of 300-468 and don't consider interop issue. -2) Use a similar approach as codec VC-1 : use the registration descriptor to carry the AV1 video descriptor.

As a reminder, please see here from h.222 the structure of the registration descriptor :

Here what VC-1 is specifying in RP227 :

My proposal would be to go with this approach, with our modified AV1 configuration record (or our AV1_video_descriptor) attached to the registration descriptor, similarly as what VC-1 is doing.

With that approach we wouldn't have to revisit the spec in the future for DVB needs.

[cconcolato]

Just to be clear, we don't intend to define subdescriptors and to have K of them, but simply say that the remaining N bytes of the registration descriptor are for the AV1 configuration record, right?

[tbiat]

Yes, except if we expect other subdescriptors to be added in the future. We can structure that in two ways :

1. Just use the remaining N bytes for the AV1 configuration record
2. Use subdescriptor mechanism with only 1 at the moment, indicating that other values are reserved for future use.

I don't see any other usage, so i would prefer to go with 1).

[tbiat]

Decision : 1-week review period. If no objection, we'll adopt this during next call (10/10/2022).

[kierank]

@cmassiot said it's fine with him