| Summary: | Regression: RTCRtpSender.getCapabilities("video") returns null on iOS 13.4 (17E5223h) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | daginge | ||||
| Component: | WebRTC | Assignee: | youenn fablet <youennf> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | commit-queue, eric.carlson, ews-watchlist, glenn, hta, jer.noble, philipj, sergio, tommyw, webkit-bug-importer, youennf | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari 13 | ||||||
| Hardware: | iPhone / iPad | ||||||
| OS: | iOS 13 | ||||||
| Attachments: |
|
||||||
Seems bad, reproed it for both audio and video. Hum, the current workaround is to instantiate a peer connection and then to call getCapabilities. Created attachment 390401 [details]
Patch
Comment on attachment 390401 [details] Patch Clearing flags on attachment: 390401 Committed r256377: <https://trac.webkit.org/changeset/256377> All reviewed patches have been landed. Closing bug. |
If you call RTCRtpSender.getCapabilities("video") on iOS 13.4, it returns null. Previously this returned an object with available codecs. Repro steps: 1. Go to https://codepen.io/daginge/full/XWbWeWN on iOS 13.4 2. Accept camera permissions (unsure if this is actually neccessary, but included it anyway) 3. See that "Available codecs" in the log is null. If you test this on 13.3 it returns as expected. Impact: We use this to determine if some legacy devices support H264 on Chrome. This falsely triggered an error message on iOS that H264 is not supported. Workaround: Just assume that iOS 13.4 supports H264 and VP8.