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
Functions deprecated in GTK3 are often used for compatibility with GTK2
builds.
MozReview-Commit-ID: F220phw3wVO
--HG--
extra : rebase_source : 128e885652b184c5a7916378d9cebb067ab97eb0
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null.
2. Called from MediaDecoder::ResourceCallback::NotifyBytesDownloaded() which is disconnected in Shutdown().
MozReview-Commit-ID: 103pxZP02Bb
--HG--
extra : rebase_source : 72e8a9c29d5ca6a4932de3a119497b05bfadbe68
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null so this must happen before Shutdown().
2. Called from SourceBuffer::Ended() where mMediaSource->GetDecoder() is not null.
3. Called from MediaDecoder::ResourceCallback::TimerCallback() which is canceled in Disconnect().
MozReview-Commit-ID: 5dqVuOcrABy
--HG--
extra : rebase_source : a134f552c4fae2317cbf93dc1e861199d4c91346
This is a follow up from bug 1289623, as I missed a few cases in that bug.
MozReview-Commit-ID: DM7FtVSZUo3
--HG--
extra : rebase_source : 4fd7ae93b1418ded54f0c21a50a654fc962d4892
