clarify which dictionary members are valid in context of encoding/decoding and type

[chcunningham]

MC was initially designed for MSE and file decoding (and mostly that's what folks have shipped). The spec has since grown to include webrtc, but many dictionary members only apply in the original MSE / file decoding contexts (for now). We should clarify that in the spec and maybe throw TypeError (or at least log a warning) if folks provide a member that isn't valid in the given context.

Here's my quick analysis of existing dictionary members:

Video

• All 'required' members make sense in all contexts
• HDR: colorGamut, transferFunction, hdrMetadataType are (for now) only useful in context of decoding MSE or file videos. May eventually make sense in encoding for record/webrtc (e.g. iPhones now record dolby vision files), but presently MediaRecorder and WebRTC (AFAIK) have no ability to configure these things.
• SVC: scalabilityMode is only useful for encoding w/ type = webrtc. referenceScaling is only useful for decoding (any type). See Use referenceScaling instead of scalabilityMode for decodingInfo queries #182.

Audio

• The required 'contentType' makes sense in all contexts
• Members bitrate and samplerate and channels have minor usefulness in file/mse decoding contexts (Trimming down the AudioConfiguration #160).
• bitrate makes sense for rtc encoding/decoding (controllable via maxBitrate) and MediaRecorder (control via bitsPerSecond)
• samplerate may or may not make sense for webrtc (Retrieving RTCRtpCodecCapability from MediaCapabilities when queried for webrtc #185 (comment)); doesn't make sense for MediaRecorder (no control)
• channels makes sense for webrtc (support mirrors what's in SDP). probably also makes sense for MediaRecorder (function of MediaStreamTrack. IIUC, MR could throw a NotSupportedError if number of channels wasn't supported. Not sure if this ever happens in practice.
• spatialRendering is about rendering, so only makes sense for decoding scenarios. Definitely file/mse types. Not sure about RTC (no spatial codec support AFAIK).

KeySystemConfig (was #166)

• Clearly only valid in non-RTC cases

Aside: some of these things may be at-risk for dropping entirely.

• I think Firefox is the only one so far to ship the encoding API for type="recorder". I haven't seen much demand for it.
• spatialRendering is half baked Trimming down the AudioConfiguration #160 (comment). So far only Safari shipped.

[chcunningham]

@aboba @drkron @jan-ivar to opine on validity for rtc and behavior (ignore, error, ...) when invalid combinations are provided.

[chcunningham]

re: invalid behavior, I propose we throw a TypeError. The alternative of ignoring invalid inputs seems less learnable for authors.

@drkron, FYI - I think this is something we should spec and implement w/ shipping of encodingInfo(). Please feel free to take the lead.

[drkron]

I'm now back from holiday and catching up on ongoing issues.

I think that TypeError sounds good. I can create a PR for this once the fix for spatialScalabilty lands.

What do you think of just specifying when it's applicable for each member?

[chcunningham]

What do you think of just specifying when it's applicable for each member?

SGTM. If not applicable -> TypeError