RESOLVED FIXED 210186
Safari doesn't apply frameRate limit when request stream from Camera
https://bugs.webkit.org/show_bug.cgi?id=210186
Summary Safari doesn't apply frameRate limit when request stream from Camera
olsviate
Reported 2020-04-08 06:50:19 PDT
Safari doesn't apply frameRate limit that is provided in constaraints for getUserMedia(). Track settings shows that provided frame rate is set, but stats shows that limit is not applied. Also it is not possible to change frame rate via MediaStreamTrack::applyConstraints(). jsfiddle: https://jsfiddle.net/sj1m6eqg/
Attachments
Patch (24.43 KB, patch)
2020-04-16 05:20 PDT, youenn fablet
no flags
Patch (24.46 KB, patch)
2020-04-16 06:39 PDT, youenn fablet
no flags
Patch for landing (24.39 KB, patch)
2020-04-17 05:45 PDT, youenn fablet
no flags
Patch (25.13 KB, patch)
2020-04-20 06:48 PDT, youenn fablet
no flags
Radar WebKit Bug Importer
Comment 1 2020-04-08 07:05:06 PDT
youenn fablet
Comment 2 2020-04-16 05:20:45 PDT
youenn fablet
Comment 3 2020-04-16 06:39:52 PDT
Eric Carlson
Comment 4 2020-04-16 07:12:44 PDT
Comment on attachment 396642 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=396642&action=review r=me once the bots are happy > Source/WebCore/platform/mediastream/RealtimeVideoSource.cpp:153 > + auto size = this->size(); Nit: this local variable is only used once now. > LayoutTests/fast/mediastream/mediastreamtrack-video-frameRate-decreasing.html:20 > + if (!stream1.getVideoTracks()[0].ended) { Is this check necessary? If so, doesn't it mean we're testing different things on different runs? > LayoutTests/fast/mediastream/mediastreamtrack-video-frameRate-decreasing.html:26 > + let frameRate = await computeFrameRate(stream2, video); Nit: this can be a const. > LayoutTests/fast/mediastream/mediastreamtrack-video-frameRate-increasing.html:26 > + if (!stream1.getVideoTracks()[0].ended) { > + const frameRate = await computeFrameRate(stream1, video); > + assert_greater_than(frameRate, 1, "stream1 frame rate above 1"); > + assert_less_than(frameRate, 20, "stream1 frame rate below 20"); > + } > + > + let frameRate = await computeFrameRate(stream2, video); Ditto the comments above.
youenn fablet
Comment 5 2020-04-16 08:02:42 PDT
Thanks for the review. (In reply to Eric Carlson from comment #4) > Comment on attachment 396642 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=396642&action=review > > r=me once the bots are happy > > > Source/WebCore/platform/mediastream/RealtimeVideoSource.cpp:153 > > + auto size = this->size(); > > Nit: this local variable is only used once now. Will fix. > > LayoutTests/fast/mediastream/mediastreamtrack-video-frameRate-decreasing.html:20 > > + if (!stream1.getVideoTracks()[0].ended) { > > Is this check necessary? If so, doesn't it mean we're testing different > things on different runs? This is to cover the case of iOS which might mute the previous track. I should replace ended by muted though. > > LayoutTests/fast/mediastream/mediastreamtrack-video-frameRate-decreasing.html:26 > > + let frameRate = await computeFrameRate(stream2, video); > > Nit: this can be a const. > > > LayoutTests/fast/mediastream/mediastreamtrack-video-frameRate-increasing.html:26 > > + if (!stream1.getVideoTracks()[0].ended) { > > + const frameRate = await computeFrameRate(stream1, video); > > + assert_greater_than(frameRate, 1, "stream1 frame rate above 1"); > > + assert_less_than(frameRate, 20, "stream1 frame rate below 20"); > > + } > > + > > + let frameRate = await computeFrameRate(stream2, video); > > Ditto the comments above. OK
youenn fablet
Comment 6 2020-04-17 05:45:48 PDT
Created attachment 396758 [details] Patch for landing
EWS
Comment 7 2020-04-17 07:22:27 PDT
Committed r260245: <https://trac.webkit.org/changeset/260245> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396758 [details].
Ryan Haddad
Comment 9 2020-04-17 12:32:55 PDT
Reverted r260245 for reason: The tests added with this change are frequently failing on macOS bots. Committed r260274: <https://trac.webkit.org/changeset/260274>
youenn fablet
Comment 10 2020-04-20 03:39:03 PDT
It seems that the release bots have issues in producing more than 10fps frame rate for capture video tracks.
youenn fablet
Comment 11 2020-04-20 06:48:28 PDT
youenn fablet
Comment 12 2020-04-20 06:49:08 PDT
Comment on attachment 396970 [details] Patch Relanding the patch with checking whether the source is producing 30fps.
EWS
Comment 13 2020-04-20 07:37:51 PDT
Committed r260364: <https://trac.webkit.org/changeset/260364> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396970 [details].
Note You need to log in before you can comment on or make changes to this bug.