FF152 MediaCapabilities.decodingInfo/encodingInfo() - config.type.webrtc option

[hamishwillee]

FF152 adds support for the configuration.type.webrtc option to be passed to MediaCapabilities.decodingInfo() and MediaCapabilities.encodingInfo() , and removes the non-standard "alias" transmission that has been around since FF63ish. The addition is behind the flag media.mediacapabilities.webrtc.enabled. Bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1825286

To do this I have created a structure of nested features to mirror the configuration option, which has type property, and below that has the new webrtc and transmission (to be removed when this is merged). Also moved an existing key below that configuraiton option.

Related docs work can be tracked in mdn/content#44174

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[hamishwillee]

This must have been wrong originally. If you look at https://hg-edge.mozilla.org/mozilla-central/rev/95e6d0dc0f14 you can see this change

 enum MediaDecodingType {
   "file",
   "media-source",
+  "webrtc",
 };
 
 enum MediaEncodingType {
   "record",
-  "transmission"
+  "webrtc",
 };

So the encoding type had the transmission option, and the decoding type did not. That is the opposite of here. I've removed it from decoding below in 3b7ccfa

[Elchi3]

To understand this PR, is the following the desired nesting?
Also, I guess, I'm a little unclear what we call parameter vs. option.

MediaCapabilities:

• decodingInfo method
  • configuration_parameter
    • keySystemConfiguration_parameter (option?)
    • type_parameter (option?)
      • webrtc_option
• encodingInfo method
  • configuration_parameter
  • type_parameter (option?)
    • transmission_option
    • webrtc_option

[Elchi3]

From https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/README.md#parameters-and-parameter-object-features

For properties of parameter objects, use a subfeature named paramname_prop_parameter with description text paramname.prop parameter, where paramname is the name of the parameter object and prop is the name of the property.

Is this the rule? I think you have more recent experience with nested data structures. Would like to hear your thoughts.

[hamishwillee]

Thanks @Elchi3.

1. Yes, I was trying to achieve exactly the nesting you show above in FF152 MediaCapabilities.decodingInfo/encodingInfo() - config.type.webrtc option #29739 (comment)
2. A parameter is a top level object, a property is a property of that object, and an option is an enumerated value of a property or parameter.
3. I updated the original pr you looked at with this commit 7d24f9e - this is based on fetch() - I got a few things wrong in the first instance. This is nested and uses the convention I understand. Note, Claude helped.
4. I updated again with another commit. This (current) version is flat, and is based on the schema link you provided. In that everything is flat, and the naming convention maps the structure. This doesn't use the term option, because the schema doesn't cover how you should document such a case.

I used to do the schema defined way, but have been told recently (and asked to modify my PRs) to support a nested form. I recalled "option" being used for enumerated values but I can't find evidence of that.
So I'd say that people are working on a new approach but that the schema has not been updated. I have partially learned that and relied on reviewers to correct me.

We this needs to be discussed in the BCD meeting to confirm the schema and naming convention to use and then I can match it. My preference is nested "FWIW" - it just feels cleaner and more logical - provided the rendering in MDN works adequately. If that happens ideally I can just drop the last commit.