Getting HTMLMediaElement's preload, defaultPlaybackRate, playbackRate attributes when playing a MediaStream must return constant values
Categories
(Core :: WebRTC: Audio/Video, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | fixed |
People
(Reporter: pehrsons, Assigned: pehrsons)
References
Details
Attachments
(11 files)
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review |
This fails a WPT that was updated for this in bug 1498058 with the comments:
Set operations for the preload, defaultPlaybackRate and playbackRate
fields should be ignored when the media element is playing a
MediaStream.
In addition, the preload field must always return "none", and
defaultPlaybackRate and playbackRate must both return 1.
Should be a simple fix.
Updated•6 years ago
|
| Assignee | ||
Comment 1•6 years ago
|
||
Depends on D33094
| Assignee | ||
Comment 2•6 years ago
|
||
Depends on D33095
| Assignee | ||
Comment 3•6 years ago
|
||
Depends on D33096
| Assignee | ||
Comment 4•6 years ago
|
||
Depends on D33097
| Assignee | ||
Comment 5•6 years ago
|
||
This does several things:
- Split the test up, so one assert doesn't fail the entire test suite
- Check preload, playbackRate and defaultPlaybackRate attributes after unsetting srcObject
- Check setting currentTime before loading (default playback start position),
and after loading (official playback position) separately - Check that duration is changed to a real number on ending
- Check that HAVE_ENOUGH_DATA is reached by only assigning srcObject
- And other minor things and formatting
Depends on D33098
| Assignee | ||
Comment 6•6 years ago
|
||
Depends on D33647
| Assignee | ||
Comment 7•6 years ago
|
||
Depends on D33648
| Assignee | ||
Comment 8•6 years ago
|
||
Bug 1279865 introduced this under the premise of
"Run TimeMarchesOn() at the beginning of play.", but it did a bit too much.
This makes us spec compliant for this particular case again.
Depends on D33649
| Assignee | ||
Comment 9•6 years ago
|
||
This FireTimeUpdate(false) dates back to bug 611994. Perhaps it was spec
compliant back in the day, but it surely isn't now.
Depends on D33650
| Assignee | ||
Comment 10•6 years ago
|
||
Depends on D33651
| Assignee | ||
Comment 11•6 years ago
|
||
Since the media element is playing directly after play(), not waiting for the
readyState to advance before play()ing could leave the play promise from play()
unhandled until cleanup, when it would be rejected by the load algorithm.
This would happen if a timeupdate event is raised before the first frame comes
in to update the readyState, which resolves the play promise.
Waiting for the readyState to advance before play()ing seems like the cleanest
fix wrt testing currentTime after the first timeupdate event.
Depends on D33655
Comment 12•6 years ago
|
||
Comment 15•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a97c295e0bcf
https://hg.mozilla.org/mozilla-central/rev/8a14b83a8b3b
https://hg.mozilla.org/mozilla-central/rev/9d311a44d2b3
https://hg.mozilla.org/mozilla-central/rev/8bdc867ea3c7
https://hg.mozilla.org/mozilla-central/rev/a6187e39bf7c
https://hg.mozilla.org/mozilla-central/rev/9f6e9bbf9e59
https://hg.mozilla.org/mozilla-central/rev/78c2ab7785eb
https://hg.mozilla.org/mozilla-central/rev/7a6d1ef04809
https://hg.mozilla.org/mozilla-central/rev/e0a7360fcc7c
https://hg.mozilla.org/mozilla-central/rev/7727cef089cd
https://hg.mozilla.org/mozilla-central/rev/89350b209bce
| Assignee | ||
Comment 16•6 years ago
|
||
James, here's another upstream PR that needs a nudge.
Description
•