Follow-up to bug 1259274, where TBM lost its inheritance.
MozReview-Commit-ID: 24tyq8tZYHp
--HG--
extra : rebase_source : 34dafd58ca0daca53649e04a0781bf6e23db3cbe
The index at which we are removing frames is always the one where we will be inserting the next ones.
MozReview-Commit-ID: DHeJDmwiMS9
--HG--
extra : rebase_source : 3730c0ed7fbdb4d9f8b4157f36aa7bb9d03a6517
P2 let all tasks run until completion, as such we don't need to deal with interrupted tasks anymore.
MozReview-Commit-ID: 45lYcIGk2ce
--HG--
extra : rebase_source : 33438284685d8f1b48f54fd109880baf0353b976
We need to ensure that the MSE TaskQueue gets shutdown as soon as possible and not wait for the MediaSource parent to be destroyed by the cycle collector.
XPCOM shutdown will deadlock if any SharedThreadPool are still in use, and it possible for the cycle collector to only occur after xpcom has shutdown.
So it's important to ensure mTaskQueue is cleared when the MediaSourceDecoder has been shutdown.
This is done by queueing a new DetachTask that will clear mTaskQueue when run.
MozReview-Commit-ID: C3FXcRtq1wy
--HG--
extra : rebase_source : 79a7c5cb451655c4679b9d4e11d0b5ca0d9814b9
This ensures that the tasks are processed in the expected order.
MozReview-Commit-ID: JPxlwReZ4Az
--HG--
extra : rebase_source : 4ffac9deaf531c9dfd8443b2e26812d7c8a89102
P2 let all tasks run until completion, as such we don't need to deal with interrupted tasks anymore.
MozReview-Commit-ID: 45lYcIGk2ce
--HG--
extra : rebase_source : db9c8db1b3f1d51d57ad090fdeb2cad6682de2be
We need to ensure that the MSE TaskQueue gets shutdown as soon as possible and not wait for the MediaSource parent to be destroyed by the cycle collector.
XPCOM shutdown will deadlock if any SharedThreadPool are still in use, and it possible for the cycle collector to only occur after xpcom has shutdown.
So it's important to ensure mTaskQueue is cleared when the MediaSourceDecoder has been shutdown.
This is done by queueing a new DetachTask that will clear mTaskQueue when run.
MozReview-Commit-ID: C3FXcRtq1wy
--HG--
extra : rebase_source : 38c0b5548b32e89b0994704c1318ff77fba76eba
This ensures that the tasks are processed in the expected order.
MozReview-Commit-ID: JPxlwReZ4Az
--HG--
extra : rebase_source : 873a373c5a6ccf20eb69f6d36b1ebdf25e6ddea3
P1 let all tasks run until completion, as such we don't need to deal with interrupted tasks anymore.
MozReview-Commit-ID: 45lYcIGk2ce
--HG--
extra : rebase_source : 87731ae2ef2c1aa2fae57ef4b232374f9ad5e0bc
We need to ensure that the MSE TaskQueue gets shutdown as soon as possible and not wait for the MediaSource parent to be destroyed by the cycle collector.
XPCOM shutdown will deadlock if any SharedThreadPool are still in use, and it possible for the cycle collector to only occur after xpcom has shutdown.
So it's important to ensure mTaskQueue is cleared when the MediaSourceDecoder has been shutdown.
This is done by queueing a new DetachTask that will clear mTaskQueue when run.
MozReview-Commit-ID: C3FXcRtq1wy
--HG--
extra : rebase_source : 034319517bd8b90668b6311efb54c3a1a864cb5b
If the last frames of a media segment were evicted due to gap detection, mLongestFrameDuration would have been reset.
Additionally, simplify the code by using temporary variables.
MozReview-Commit-ID: HCjuZkgwANN
--HG--
extra : rebase_source : eed2837fd4b05fe3f7c4774c4486a201d0100cf7
This makes us closer to the spec, while still allowing some leeway in gap detection which was found to too strict in the past.
MozReview-Commit-ID: 9EPT2e2F6ed
--HG--
extra : rebase_source : 2bdc01667c3aaeae7a72eb5c6861076113a34c59
Also, remove no longer used code and update comments to properly reflect the current algorithms used.
MozReview-Commit-ID: GwsGC70xM85
--HG--
extra : rebase_source : 2c1a2cd449eac243d8e3d77cc1bf80c2adc64cdf
It was possible for a TrackBuffersManager to have pending tasks currently running while the MediaSourceDemuxer was shutting down the task queue. This would cause an assertion upon resolution of the promise attempting to schedule a new runnable as the task queue was now shutdown.
The AutoTaskQueue only shuts down once it's no longer used.
MozReview-Commit-ID: IzPh2OdGbvN
--HG--
extra : rebase_source : 3b39ca72f1bbb1d64e7f9f7a376b5b9cb68da0f6
We now longer require an abstraction layer with the TrackBuffersManager now that the old MSE has been removed.
MozReview-Commit-ID: 3uEejohvFQD
--HG--
extra : rebase_source : 2e89fe4c7b9d13910fb6f26f0090fca26d19726f
* Move eviction handling out of SourceBuffer into TrackBuffersManager
* Separate audio and video eviction thresholds
* Reduce default audio eviction threshold to 15MB
Also, an assert could have been incorrectly triggered, if eviction occurred on a source buffer while data was also being appended to it.
MozReview-Commit-ID: 6gVHZdbL07B
Also, an assert could have been incorrectly triggered, if eviction occurred on a source buffer while data was also being appended to it.
MozReview-Commit-ID: 6gVHZdbL07B
The W3C spec indicates that while everything in MSE is asynchronous, the abort() command is to interrupt the current segment parser loop and have the reset parser loop synchronously completes the frames present in the input buffer.
This causes a fundamental issue that abort() will never result in a deterministic outcome as the segment parser loop may be in different condition.
We used to really attempt to abort the current operation, however there could have been a race in the order in which tasks were queued. As such, we now simply wait for the current appendBuffer to complete.
This also simplifies the code greatly, as we don't need to worry about pending concurrent appendBuffer.
The actually happens to be similar to the Chromium behavior.
Similar to bug 1239983, we strongly assert should a segment parser loop be running when it must have completed.
MozReview-Commit-ID: 9772PLQEozf
It served no purpose other than implementing the MSE spec by the letter. The spirit is preserved.
This allows to disable tail dispatching on the MediaSourceDemuxer's TaskQueue which prevents us from performing synchronous operation on the main thread.
MozReview-Commit-ID: G7aqfvGsf1e
mAppendRunning is set prior the append task being queued; so it is possible that the segment parser loop hasn't yet been started, yet mAppendRunning is true.
Separate this diagnostic with a new flag ON A CLOSED TREE.
MozReview-Commit-ID: GgTyyltKOJr
The W3C spec indicates that while everything in MSE is asynchronous, the abort() command is to interrupt the current segment parser loop and have the reset parser loop synchronously completes the frames present in the input buffer.
This causes a fundamental issue that abort() will never result in a deterministic outcome as the segment parser loop may be in different condition.
We used to really attempt to abort the current operation, however there could have been a race in the order in which tasks were queued. As such, we now simply wait for the current appendBuffer to complete.
This also simplifies the code greatly, as we don't need to worry about pending concurrent appendBuffer.
The actually happens to be similar to the Chromium behavior.
Similar to bug 1239983, we strongly assert should a segment parser loop be running when it must have completed.
MozReview-Commit-ID: 9772PLQEozf
It served no purpose other than implementing the MSE spec by the letter. The spirit is preserved.
This allows to disable tail dispatching on the MediaSourceDemuxer's TaskQueue which prevents us from performing synchronous operation on the main thread.
MozReview-Commit-ID: G7aqfvGsf1e
The W3C spec indicates that while everything in MSE is asynchronous, the abort() command is to interrupt the current segment parser loop and have the reset parser loop synchronously completes the frames present in the input buffer.
This causes a fundamental issue that abort() will never result in a deterministic outcome as the segment parser loop may be in different condition.
We used to really attempt to abort the current operation, however there could have been a race in the order in which tasks were queued. As such, we now simply wait for the current appendBuffer to complete.
This also simplifies the code greatly, as we don't need to worry about pending concurrent appendBuffer.
The actually happens to be similar to the Chromium behavior.
MozReview-Commit-ID: CHppUOGM1mk
Gerald Squelart
Jonathan Watt
Jean-Yves Avenard
Sebastian Hengst
Ryan VanderMeulen
Eugen Sawin
Wes Kocher
Phil Ringnalda
Carsten "Tomcat" Book