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 puts all the logic in GetUserMediaCallbackMediaStreamListener and none in
MediaOperationTask to make it simpler to reason about what's happening.
When we want to stop a track, the gUMCallbackListener will send a
MEDIA_STOP_TRACK if other tracks will still be live.
If it was the last live track, the gUMCallbackListener will send a MEDIA_STOP
instead. The MEDIA_STOP makes sure the passed in devices (we pass in all) are
stopped before finishing the stream.
MozReview-Commit-ID: E43Iqw491tB
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
The once function should add and then remove an event listener after it is
invoked, but it appears to remove another event listener instead. This commit
adjusts that behaviour. Note that the dom/media/mediasource/test/mediasource.js
file has the same pattern and has been updated. This commit reflects using the
same changes to remedy the once function here.
MozReview-Commit-ID: DQ4bfxTQfjN
--HG--
extra : transplant_source : 7%8E%19%DB74e%23%1511%1C%89%7D5%98%DE%12%BA%A2
This is a partial reversal of bug 1230338. We can't distinguish frames that are never composited because the media element is hidden from the frames genuinely dropped due to machine slowness. So until we can distinguish them, let's not report them as dropped.
MozReview-Commit-ID: ERV8Luaxp3F
All the methods in CDMProxy except CDMProxy::OnExpirationChange() that use
mKeys null check mKeys before using it because it can go away during shutdown
before the IPC message to call the methods have had a chance to run.
We should do the null check in CDMProxy::OnExpirationChange() too.
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.
Initialize all WebMBufferedParser members, mainly to remove compiler warnings.
'mClusterTimecode' and 'mClusterOffset' are probably genuine potential issues,
see bug 1143096 comment 2 for details.
