The seeking attribute is changed synchronously, however, the seeking event is fired asynchronously. It is possible that by the time the seeking event is fired, the seeking operation has already completed and that the "time marches on", causing currentTime to be past the seeking position.
MozReview-Commit-ID: IB83w6zKCLF
--HG--
extra : rebase_source : 524519b526b04a4b13a4531f5460c2fbe57f218a
The test should pass now, we do not need different expected results file.
MozReview-Commit-ID: Cl3GBRx1ISN
--HG--
extra : rebase_source : 59a90e20ada254b2a4c65bca34b21cde58a11b0c
It is invalid to assume that no other actions can be performed between the time setTimout is called with a timeout value of 0 and the task actually runs.
This causes events to be regularly missed.
MozReview-Commit-ID: 70dtFsTwETf
--HG--
extra : rebase_source : 15ee481266ec1c8a0db10ee70cc44eefbd8129c5
This doesn't include tests for this behavior, because I'm not sure there's a
good way to test it reliably.
MozReview-Commit-ID: CM5rj1f9YiG
--HG--
extra : rebase_source : 11608a2d0b78802021a4f8aec39f0caa2f75af2c
Calling NotifyDataArrived from each sourcebuffer will cause multiple unnecessary NotifyDataArrived to the MediaFormatReader when it could only be done once. Additionally, it ensures that the media duration is updated prior to the reader actioning on the notification.
Extra: mEnded is only ever accessed on the main thread, there's no need to make it atomic.
MozReview-Commit-ID: IKq7IRBbWic
--HG--
extra : rebase_source : 6cf18b1f71f5ee6c8e82c73bdd2857e783f343b8
The duration in the MediaDecoder is the canonical. It has as such a more up to date value than the mirror.
Under some circumstances, the MDSM may have reached the end of media playback before the duration mirror had time to update. So perform the currentTime adjustment in the MediaDecoder instead.
MozReview-Commit-ID: 1RFr4mT5LpA
--HG--
extra : rebase_source : 3151d86561b53d5d1922c7c16f042792bfd47283
With MediaSource, the duration is always known and exact. It is entirely possible that we have played data at some point, then removed that data and adjusted the duration.
MozReview-Commit-ID: HZe2yXtQfIL
--HG--
extra : rebase_source : be1b57575c28142d6b3091b23894a7e4e1c9b405
See w3c/MSE Issue 19, 20 & 26.
Changing the duration now can never call the range removal algorithm. An explicit call to remove must be used for range removal.
This spec change performed the following:
- Require remove() for all Range Removals
MozReview-Commit-ID: 860PnQ9yrbc
--HG--
extra : rebase_source : 31591e537706979cccedfedb2f2320b0c9681d22
It is incorrect to assume that the seeking attribute will still be true once the seeking event handler gets to run. Seeking may have completed between the time the seeking event was queued and the time the seeking env is fired.
MozReview-Commit-ID: CZFFotMyaIu
--HG--
extra : rebase_source : 32f9b56520020aaad26cc4564cf9f15ddad8d055
Back when it was added, it was used, but it is not anymore, outside
test_base.py.
--HG--
extra : rebase_source : f0b9a4dab2985e89e9950eda774ae853c7de764c
We've been reading the mozconfig in MozbuildObject.from_environment to
check whether the mozconfig topobjdir matches the detected topobjdir.
Since bug 1278415, everything using the buildconfig python module now
calls MozbuildObject.from_environment, which reads the mozconfig. A lot
of things to that during the build. But none of them actually need the
data from the mozconfig, and the topobjdir match test has been breaking
things randomly on multiple occasions.
The topobjdir match test, however, really only needs to happen once:
when a mach command starts. So we can move the test to MachCommandBase,
where it belongs, and anything actively using MozbuildObject.mozconfig
will have the mozconfig read, but everything else won't.
On a Linux64 opt build, this brings down the number of times the
mozconfig is read during `mach build` from 979 to 9.
--HG--
extra : rebase_source : 6b340f1fcf73a3c3987033c37f8f14ef06a44f04