Closed tidoust closed 1 year ago
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.
@aboba @padenot did you want to weigh in before we merge @tidoust 's proposal?
The proposal from @tidoust looks good, taking into account https://github.com/w3c/webcodecs/issues/571#issuecomment-1265716042, 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 https://github.com/w3c/webcodecs/pull/559, do we want to change the return type?
I have reviewed PR https://github.com/w3c/webcodecs/pull/572 (it looks fine).
As mentioned in https://github.com/w3c/webcodecs/pull/559#pullrequestreview-1127954467, there is one requirement mandated by the Process Document for registry definitions that the current spec does not describe:
As a straw-man proposal, I would suggest:
What do you think?