[WebCodecs codec registry] Policy for changes to existing entries

[tidoust]

As mentioned in #559 (review), there is one requirement mandated by the Process Document for registry definitions that the current spec does not describe:

Define the policy for changes to existing entries, such as

• whether entries can be deleted or deprecated
• whether entries can be changed after being published, and what kinds of changes are allowed
• whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely

As a straw-man proposal, I would suggest:

• entries can be deprecated but not deleted
• The codec string may be completed, the public specification may be updated. All changes SHOULD be backward compatible. To be evaluated by the Media WG.
• identifiers are reserved indefinitely

What do you think?

[dalecurtis]

• I don't think we'd ever want to deprecate or delete since it's non-normative. A codec wouldn't simply disappear; especially since we require additions to go through the Media WG. I suppose there could be non-technical reasons we have to remove a codec though...
• Changes can be allowed. I would say the base codec string can't be deleted, but it can be extended. E.g., vp09 to vp09.aa.bb.cc.dd.ee.ff. I expect we'll also see things like configuration dictionaries added for more codecs than avc; though we'll have to think on the spec side how we want those feature detectable. @sandersdan
• Since no deletion, no reuse.

[sandersdan]

we'll have to think on the spec side how we want those feature detectable.

There is only one proposed path for mutating metadata (a VideoFrame construction option), and it would be passively detectable in that metadata that doesn't match a known key would not appear on the constructed VideoFrame.

The primary alternative would be to add an interface that we return from metadata() rather than re-using the dictionary type; that way there would be a JS object available to be introspected.

Edit: for encoder/decoder configurations, isConfigSupported() returns the configuration, this allows apps to check which configuration options were understood.

[dalecurtis]

@aboba @padenot did you want to weigh in before we merge @tidoust 's proposal?

[chrisn]

The proposal from @tidoust looks good, taking into account #571 (comment), although, as I understand it, adding configuration options would affect the codec-specific registrations rather than the registry (i.e., the mapping document) itself.

The part of @sandersdan's comment on returning an interface or dictionary type from metadata() applies to #559, do we want to change the return type?

[aboba]

I have reviewed PR #572 (it looks fine).