WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(24.46 KB, patch)
2020-04-16 06:39 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch for landing
(24.39 KB, patch)
2020-04-17 05:45 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch
(25.13 KB, patch)
2020-04-20 06:48 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2020-04-08 07:05:06 PDT
<
rdar://problem/61452794
>
youenn fablet
Comment 2
2020-04-16 05:20:45 PDT
Created
attachment 396636
[details]
Patch
youenn fablet
Comment 3
2020-04-16 06:39:52 PDT
Created
attachment 396642
[details]
Patch
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 8
2020-04-17 12:26:06 PDT
It looks like all the tests added with this change are failing more often than they are passing on macOS release bots:
https://results.webkit.org/?suite=layout-tests&suite=layout-tests&suite=layout-tests&suite=layout-tests&test=fast%2Fmediastream%2Fmediastreamtrack-video-frameRate-clone-decreasing.html&test=fast%2Fmediastream%2Fmediastreamtrack-video-frameRate-clone-increasing.html&test=fast%2Fmediastream%2Fmediastreamtrack-video-frameRate-decreasing.html&test=fast%2Fmediastream%2Fmediastreamtrack-video-frameRate-increasing.html
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
Created
attachment 396970
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug