Repository navigation
Conversation
|
This seems like a good improvement to the correctness of the API, mostly I'd like to assess risk of backwards compatibility issues. Can there be an accompanying PR against the web platform tests to check the behavior change? |
|
web-platform-tests/wpt#63909 updates the WPT for this behavior change. Here is a summary of how they impact Chrome stable channel: Media Capabilities WPT Results in Chrome (
|
| Test File | Baseline Pass / Total (Fail) | Updated Pass / Total (Fail) | Delta |
|---|---|---|---|
decodingInfo-webrtc.any.html |
37 / 44 (7 FAIL) | 41 / 52 (11 FAIL) | +4 PASS, +4 FAIL |
decodingInfo-webrtc.any.worker.html |
16 / 23 (7 FAIL) | 20 / 31 (11 FAIL) | +4 PASS, +4 FAIL |
encodingInfo-webrtc.any.html |
28 / 34 (6 FAIL) | 32 / 42 (10 FAIL) | +4 PASS, +4 FAIL |
encodingInfo-webrtc.any.worker.html |
14 / 20 (6 FAIL) | 18 / 28 (10 FAIL) | +4 PASS, +4 FAIL |
decodingInfoEncryptedMedia.https.html |
21 / 21 (0 FAIL) | 21 / 21 (0 FAIL) | Unchanged |
decodingInfoEncryptedMedia.http.html |
1 / 1 (0 FAIL) | 1 / 1 (0 FAIL) | Unchanged |
decodingInfo.any.html |
26 / 34 (8 FAIL) | 26 / 34 (8 FAIL) | Unchanged |
decodingInfo.any.worker.html |
26 / 34 (8 FAIL) | 26 / 34 (8 FAIL) | Unchanged |
encodingInfo.any.html |
25 / 27 (2 FAIL) | 25 / 27 (2 FAIL) | Unchanged |
encodingInfo.any.worker.html |
25 / 27 (2 FAIL) | 25 / 27 (2 FAIL) | Unchanged |
idlharness.any.html |
38 / 38 (0 FAIL) | 38 / 38 (0 FAIL) | Unchanged |
idlharness.any.worker.html |
38 / 38 (0 FAIL) | 38 / 38 (0 FAIL) | Unchanged |
2. Subtest Differences (decodingInfo & encodingInfo, Window & Worker)
| Subtest & Notes | contentType |
Base | PR #259 |
|---|---|---|---|
Existing (video): non-codecs param resolves to supported: false (previously expected TypeError) |
video/webm; foo="bar" |
FAIL | PASS |
Existing (audio): non-codecs param resolves to supported: false (previously expected TypeError) |
audio/webm; foo="bar" |
FAIL | PASS |
Existing (video): non-webrtc with codecs rejects with TypeError (Chrome resolves supported: false) |
video/webm; codecs="vp09..." |
PASS | FAIL |
Existing (audio): non-webrtc with codecs rejects with TypeError (Chrome resolves supported: false) |
audio/webm; codecs="opus" |
PASS | FAIL |
New (video): profile param without codecs resolves |
video/VP9; profile-id="0" |
— | PASS |
New (audio): fmtp param without codecs resolves |
audio/opus; stereo=1 |
— | PASS |
New (video): no params resolves with supported: true |
video/VP9 |
— | PASS |
New (audio): no params resolves with supported: true |
audio/opus |
— | PASS |
New (video): codecs param rejects with TypeError (Chrome resolves) |
video/VP9; codecs="vp09..." |
— | FAIL |
New (audio): codecs param rejects with TypeError (Chrome resolves) |
audio/opus; codecs="opus" |
— | FAIL |
New (video): codecs + profile params rejects with TypeError (Chrome resolves) |
video/VP9; codecs="..."; profile-id="0" |
— | FAIL |
New (audio): codecs + fmtp params rejects with TypeError (Chrome resolves) |
audio/opus; codecs="..."; stereo=1 |
— | FAIL |
| <ol> | ||
| <li> | ||
| If the <code>parameters</code> member of |mimeType| contains a | ||
| key named "codecs", return <code>false</code>. |
There was a problem hiding this comment.
Do we anticipate this being backwards incompatible with existing usages of the API? It would be less risky to just ignore the codecs key if passed with a webrtc type.
However, from the discussion in the bug, it sounds like that for the webrtc use case the codecs parameter is useless and must be accompanied by a profile parameter to correctly identify the media during negotiation. So WebRTC applications relying on codecs alone are probably not going getting any reliable information from the API to begin with.
What about applications that are passing contentType: "video/H264; codecs=aabbccdd; profile-level-id=xxyyzz" - should they be allowed to pass this gate by ignoring the codecs parameter?
| <ol> | ||
| <li> | ||
| If |encodingOrDecodingType| is {{MediaEncodingType/webrtc}} ({{MediaEncodingType}}) | ||
| or {{MediaDecodingType/webrtc}} ({{MediaDecodingType}}) and |mimeType| is not one |
There was a problem hiding this comment.
We also check here that the webrtc mime types are "used with RTP." If we did allow contentType: "video/H264; codecs=aabbccdd; profile-level-id=xxyyzz" through to here, we could ignore the codecs and treat it as contentType: "video/H264; profile-level-id=xxyyzz", or fail such a type description as unsupported because it doesn't map into anything in RTP.
Fixes #238.
Preview | Diff