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 changes that follow may cause the active sourcebuffer list to be modified; which will trigger an assertion if the mediasource object is closed.
MozReview-Commit-ID: 8A1CMKAUyTq
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 changes that follow may cause the active sourcebuffer list to be modified; which will trigger an assertion if the mediasource object is closed.
MozReview-Commit-ID: 8A1CMKAUyTq
This is similar to bug 1239983, we strongly assert should a segment parser loop be running when it must have completed.
MozReview-Commit-ID: CXqGoq9Opq0
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
The changes that follow may cause the active sourcebuffer list to be modified; which will trigger an assertion if the mediasource object is closed.
MozReview-Commit-ID: 8A1CMKAUyTq
YouTube sets the track ID at 1 for both audio and video tracks. Attempting to use mozCaptureStream would cause an assert as it always expect tracks to have a different track Id.
Added diagnostics around demuxer init/reset promises, to catch early cases
where TrackBuffersManager::mInputDemuxer is destroyed while an init/reset
promise is in flight, which would cause later issues when the 'Then' clause
assumes that mInputDemuxer still exists.
Note: This is *not* an actual fix for crashes linked to this bug, but it should
help identify unexpected situations, or instead eliminate these patched
locations as sources of crashes.
A new bug will be needed to examine the fallout from this patch and produce a
real fix, or continue investigating.
XPCOM when shutting down expects all tasks to be run synchronously. As such, we must ensure that the remaining MediaDecoder are shut down before continuing on the next task.
In particular destroying gfxPlatforms must only ever happen after, as it is possible for the MediaDecoderReader to make use of gfx resources during shutdown.
When seeking, the next keyframe time would always be set to the seek time (as the next sample to be retrieved would be a keyframe). This could lead to the next key frame logic to be activated too aggressively.
When seeking, the next keyframe time would always be set to the seek time (as the next sample to be retrieved would be a keyframe). This could lead to the next key frame logic to be activated too aggressively.
We assume that if we have 30s of data buffered ahead of the current position or up to the element's duration that we can play ahead without interruption.
We require a slightly variation on the default implementation as mediasource allows for gaps of up to 125ms between samples and often videos do not start with a time of 0.
Jean-Yves Avenard
Phil Ringnalda
Carsten "Tomcat" Book
Bryce Van Dyk
Gerald Squelart
Kyle Huey
Guang-De Lin
Chris Peterson