-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should VideoEncoderConfig cloning remove parameters that are not useful for a given codec? #681
Comments
The intent was to support feature detection. More generally, the returned configuration should be the user agent's interpretation of the supplied configuration. I would say that the spec as written implies that all known IDL properties should be copied. For the purpose of a developer debugging WebCodecs operation, I'd say that Chrome's behavior is perhaps more helpful. Based on that, I would vote for Chrome's behavior, but it might not have an obvious algorithm to specify. |
I would think feature detection is done at WebIDL level, parameters not recognised will not be copied. Overall, we might end up in bad interop here between browsers, which might be more hurtful than anything else. |
I suppose that's the key question. Right now I don't think we have any options that make sense to support only in some codecs, except for the explicitly codec-specific options. I can imagine bitrate control getting complex enough to have variability, but that hasn't happened yet. I think I'm comfortable with either fixing Chrome to match the current spec, or changing the spec to exclude coded-specific options that do not apply to |
I think I would prefer this at it is simpler to spec and implement. |
I think feature detection won't suffer if we just clone every field known to the user agent. Codec specific fields that belong to a different codec don't have any effect anyway. As for hints, they need to be copied if the user agent knows about them regardless if they had any real effect on configuration of the underlying encoder. |
Media WG discussion on 7/11/2023:
|
…dec specific fields Update test according decision from w3c/webcodecs#681
WPT PR up for review. |
…dec specific fields (#41824) Update test according decision from w3c/webcodecs#681
…onfiguration needs to copy codec specific fields, a=testonly Automatic update from web-platform-tests https://w3c.github.io/webcodecs/#clone-configuration needs to copy codec specific fields (#41824) Update test according decision from w3c/webcodecs#681 -- wpt-commits: 7d62dd075bbd5535cd6a90028a85b5f6534d083d wpt-pr: 41824
…onfiguration needs to copy codec specific fields, a=testonly Automatic update from web-platform-tests https://w3c.github.io/webcodecs/#clone-configuration needs to copy codec specific fields (#41824) Update test according decision from w3c/webcodecs#681 -- wpt-commits: 7d62dd075bbd5535cd6a90028a85b5f6534d083d wpt-pr: 41824
…dec specific fields (web-platform-tests#41824) Update test according decision from w3c/webcodecs#681
According https://w3c.github.io/webcodecs/#clone-configuration, the configuration should be cloned, hence all members of VideoEncoderSupport should be copied.
Chrome in https://wpt.live/webcodecs/video-encoder-config.https.any.html assumes that the
avc
member will not be cloned if thecodec
is vp8. Safari simply clones all members it knows.The note in https://w3c.github.io/webcodecs/#dom-videoencoder-isconfigsupported says that only
recognised
dictionary members will be copied.recognised
could be interpreted both ways.It would be good to clarify the intent here.
The text was updated successfully, but these errors were encountered: