Current downmixer was using vorbis channel order (which isn't surprising as it was extracted from the Ogg reader).
Make it use SMPTE order as that's now what all MediaDataDecoder output.
MozReview-Commit-ID: 5Kf7UnC52wL
--HG--
extra : rebase_source : b8499b8abbe2aa7a37acea19d3d33edc3d41e8a3
To be used in combination with AudioDataBuffer class that will be able to perform format conversion.
Can currently only perform channel re-ordering.
Future use will add downmixing, upmixing and resampling capabilities.
MozReview-Commit-ID: 2FBu9aRVtgj
--HG--
extra : rebase_source : c271d94e597b529bdad57aa8f18f0dd7b2cf71ec
Long term goal would be to merge AudioConfig with the existing AudioInfo class which doesn't provide sufficient data to properly determine how to play multichannel audio.
MozReview-Commit-ID: 3UDpZWPBUvS
--HG--
extra : rebase_source : 324c0f0c19d7faf1e1efecf6b1805dd7b5edd4a6
Along with AlignedByteBuffer and AlignedFloatBuffer
MozReview-Commit-ID: LmGc2JDBETi
--HG--
extra : rebase_source : d94b19c264e603f046c46f5d5335f9f2c3508c7f
The idea is that we can call Ensure{Audio/Video}DecodeTaskQueued() directly
since the conditions in the DispatchDecodeTasksIfNeeded() have already been
checked.
MozReview-Commit-ID: 9xataQiuSIx
--HG--
extra : transplant_source : %E4t%20%1FV%12%FE%08%9Cx%D7%0A%C3C%B0M%14%80%E4%85
That this caused problems is probably related to video not being supported for
direct track listeners. Frames could pile up under load and delay the MSG
since there were so many frames queued for processing.
With a direct listener the MediaPipeline processing would occur on the
MediaEngine's thread.
MozReview-Commit-ID: DjKblA7dMz9
--HG--
extra : rebase_source : 60bbc5f1add65f3cf5c2cfeadb915c79d33acc0a
extra : source : 6e6636eea735795dfcae9779ea8f71e8df9516ce
Not sure why this surfaced now. Include ordering must have changed.
MozReview-Commit-ID: 43eGMdVoycw
--HG--
extra : rebase_source : 5013c1bb93060ea593bca96fe84f3418ea1aefa3
HTMLMediaElement needs special protection when playing a stream since its
ImageContainer can outlive the video track of a stream.
Consider for instance when a (cross-origin) video track is removed from a
DOMMediaStream by a user and the remaining video track (non-CORS) does not yet
contain any actual video frames. The HTMLMediaElement will display a frame from
the removed track but the DOMMediaStream's principal has been updated to not
include the principal from the removed track.
With this patch we handle this by letting VideoFrameContainer notify
HTMLMediaElement when it has flushed out all video frames belonging to a
certain PrincipalHandle. I.e., when a new PrincipalHandle has been applied to the
underlying ImageContainer.
MozReview-Commit-ID: LvIZPl6Rdgj
--HG--
extra : rebase_source : cfbad5e5e7f43af4da4bfc213494b7b8e22cde17
Calculating a principal when adding a track is easy - just combine the new
track principal into the stream's principal.
When removing a track it's a bit trickier. The DOMMediaStream has to wait until
the MediaStreamGraph has removed the track from the underlying playback stream.
We do this by letting the MediaStreamGraph return a Pledge (single threaded
Promise) when blocking a track in a stream (the way we end removed tracks).
The pledge gets passed to the MediaStreamGraph and when the block has been
applied it is passed back to the main thread where it is finally resolved
and the DOMMediaStream may recompute its principal once all outstanding
track removals have been applied.
MozReview-Commit-ID: 3QP0YcDyfGf
--HG--
extra : rebase_source : 6642849ec1c7d774467395dee82b0a37fdd33a99
PrincipalHandle is a thread safe pointer to a holder of (the main-thread-only
nsIPrincipal) that can be passed around the MSG.
A MediaStreamTrack whose source has just updated its principal, sets the new
principal aside (as its "pending principal"), and combines the new principal
into its current principal.
Then the source starts passing the new principal to the MediaStreamGraph as
a PrincipalHandle.
Changes to a track's PrincipalHandle on the MSG will be surfaced through the
MediaStreamTrackListener API. These changes are dispatched to main thread
and compared to a MediaStreamTrack's pending principal. In case of a match
the track knows the correct principal is flowing and can move the pending
principal to be the current principal and update any main thread principal
observers.
MozReview-Commit-ID: D0JXGWhQFFU
--HG--
extra : rebase_source : 296e269bb46fc5a85a9c3f90dfc0dc40e53572bc
LoadManagerSingleton has a separate shutdown path (xpcom-shutdown) from
its users (Audio/VideoConduit - garbage collected). These have appeared
racy, so in some cases the singleton was destructed before the users had
deregistered (e.g., when conduits destructed by SnowWhiteKiller).
A WeakPtr can solve this.
MozReview-Commit-ID: AVrpd3QqOGx
--HG--
extra : rebase_source : c5d50f7619940b772c7d1f3dee3ac0b6568ccfd9
Disabling the audio analyser debug canvas gave us enough perf to enable
the test reliably here.
MozReview-Commit-ID: AGEfsD4pyME
--HG--
extra : rebase_source : 2d379717028d748eb8f6e72bffbc8b20e3ec10b8
It does not leak anymore, and the exception from bug 919051 is not
in the spec.
MozReview-Commit-ID: Kw6OpaJllyR
--HG--
extra : rebase_source : 6d7294a53c9e02af2085cb86d67530cf4cf20ab0
