Spec (being written): https://github.com/WebAudio/web-audio-api/issues/1139
Bug 1343550 - Prevent touching promises when shutting down an AudioContext, when the global is going away soon. r=baku
MozReview-Commit-ID: F6en9KEbNNf
--HG--
extra : rebase_source : 04076caa38bba980cdff776b5997f33e24516d9e
extra : intermediate-source : 4f2cd3f715a218dc3bca55e89720b6aa1040d35c
extra : source : 69cd9c72bd4ed419e3f7f7b5ab64ee0fa8bd89a2
Note we can't simply change the type of AMPLE_AUDIO_USECS to TimeUnit because it is
used in a static_assert and TimeUnit::ToMicroseconds() is not a const expression.
There is no easy way to change it because CheckedInt::value() calls MOZ_ASSERT which
can't be a const expression.
MozReview-Commit-ID: 17qaTFOOLpL
--HG--
extra : rebase_source : 30d20d681d64cae35e0a56e9c6113afd1a712548
extra : source : bb1e3ec2bc37b0c0c7377dd78d935f60fca3a643
When we shutdown the browser while the GMPService is active we can end up
leaking a GMPParent, GeckoMediaPluginServiceParent, and a Runnable. I tracked
this down to the runnable dispatched to the GMP thread in
GMPParent::ChildTerminated(). The dispatch of this runnable is failing as we
are dispatching the runnable to a reference of the GMP thread which we have
previously acquired, but that thread is now shutdown. So the dispatch fails,
and if you look in nsThread::DispatchInternal() you'll see that we deliberately
leak the runnable if dispatch fails! The runnable leaking means that the
references it holds to the GMPParent and the GMP service parent leak.
The solution in this patch is to not cache a reference to the GMP thread on the
GMPParent; instead we re-request the GMP thread from the GMPService when we
want it. This means that in the case where the browser is shutting down,
GMPParent::GMPThread() will return null, and we'll not leak the runnable. We'll
then follow the (hacky) shutdown path added in bug 1163239.
We also need to change GMPParent::GMPThread() and GMPContentParent::GMPThread()
to return a reference to the GMP thread with a refcount held on it, in order
to ensure we don't race with the GMP service shutting down the GMP thread
while we're trying to dispatch to in on shutdown.
MozReview-Commit-ID: CXv9VZqTRzY
--HG--
extra : rebase_source : e507e48ee633cad8911287fb7296bbb1679a7bcb
We often need to turn on both MediaSample and MediaDecoder logs when debugging sample activities.
So it is convenient to merge them into a single log module.
Use `MOZ_LOG=MediaDecoder:4` to show decoder logs.
use `MOZ_LOG=MediaDecoder:5` to show both decoder and sample logs.
MozReview-Commit-ID: JQtyoyrNRmV
--HG--
extra : rebase_source : 85739da85aa4059b058a9baccd5509c8149712d8
1. Use LOG() for OnMediaSink{Audio,video}Complete() which is not verbose.
2. Use LOGW() for OnMediaSink{Audio,Video}Error() which indicates an error.
MozReview-Commit-ID: 4Z5U32YlMPB
--HG--
extra : rebase_source : 2b2da51c17b6c7d9b4ec8b0f274c9ed018631374
X11.h #defines 'Status' and 'Failed' and 'Succeeded' which conflicts with
the enum in DetailedPromise. So rename the 'Status' enum in DetailedPromise
so that the build works on Linux.
Some of my changes here caused DetailedPromise to be included in more
places that it was before, which caused build failures on Linux.
MozReview-Commit-ID: KV5xKixXR3J
--HG--
extra : rebase_source : ef6cab901d74b78f613660f263f5e453d6044536
This is required for the browser clearing persistence tests to pass.
MozReview-Commit-ID: Ai9qc6Ds1IG
--HG--
extra : rebase_source : 80c2133e26742410fda983e3c18c35736fc013d0
This severs the ChromiumCDMVideoDecoder's connection with the CDM. The CDM process
will shutdown when the MediaKeys also severs its connection.
MozReview-Commit-ID: Aqc4y5Nxjvc
--HG--
extra : rebase_source : 5a2f77ffe84f9b99b4668520c838b29a428578d3
At this stage, I store video frames in memory in nsTArrays rather than in
shmems just so we can get this working. Once this is working, I'll follow up
with patches to switch to storing all large buffer traffic between the CDM and
other processes in shmems.
I'm not planning on preffing this new CDM path on until that's in place.
MozReview-Commit-ID: LSTb42msWQS
--HG--
extra : rebase_source : b7f162515a1a32b2c344c11d0fa5c7004cec2e15
The MediaKeys accesses the ChromiumCDMProxy on the main thread. But the
ChromiumCDMVideoDecoder will need to access the ChromiumCDMProxy on the decode
task queue in order to get a reference to the ChromiumCDMParent so that it can
talk to the CDM (on the GMP thread).
Additionally we'll need to shutdown the ChromiumCDMProxy, and if we do that
on the main threrad while the ChromiumCDMVideoDecoder is trying to get the
ChromiumCDMParent reference, we could hit thread safety issues.
So we need to hold a lock while reading or writing from the ChromiumCDMProxy's
reference to the ChromiumCDMParent. So add a GetCDMParent() function to the
ChromiumCDMProxy which takes the lock while reading or writing the reference.
This means that the caller will always get a valid reference. There is no guarantee
that the ChromiumCDMParent isn't shutdown after the reference is taken; if that
happens, the ChromiumCDMParent returned will fail on all operations.
In a later patch in this series, the ChromiumCDMProxy will anull its reference
to the ChromiumCDMParent on shutdown, and cause GetCDMParent to return null.
So callers need to null check the return value of GetCDMParent.
MozReview-Commit-ID: 4xL41YbwkxL
--HG--
extra : rebase_source : aa854e9d88965d7da60231d6f6a3912bf6ad2eeb
Under some circumstances, and seen on Windows 8, a decoded sample can be returned without the MFT returning MF_E_TRANSFORM_STREAM_CHANGE.
For historical reasons, we required that message to be returned at least once to set the output image size. This was required as the decoder used to be recycled with different video streams.
This is no longer the case, we can rely on the video info instead. It also greatly simplifies the code
MozReview-Commit-ID: H14KBiNWrjQ
This mMediaTracksConstructed flag should belong to a MediaDecoder,
every time a HTMLMediaElement switches its MediaDecoder, the flag should be reset to false again.
So, we move the mMediaTracksConstructed flag back to MediaDecoder, by this way,
HTMLMediaElement provides only the mechanism to construct and remove media tracks,
and MediaDecoder uses the flag, mMediaTracksConstructed, to provide policy.
MozReview-Commit-ID: L7mMAmLjQCy
--HG--
extra : rebase_source : 1625d604afb34bffe79eda06a46c9feb780a14d9
If a media element is in-tree with UNTRACKED visibility state, the information is incomplete, just ignore it.
MozReview-Commit-ID: FcKybQZqF6c
--HG--
extra : rebase_source : 0d10cf1b80189db200999b3881f42773c34ad798
In bug 1346987 we're attempting to remove uses of the
NS_OpenAnonymousTemporaryFile() in the content process as it sends a
synchronous IPC to the parent process on the main thread, which can cause UI
jank. This patch makes the MediaCache use the async anonymous temporary file
creation function added in bug 1346987.
The file descriptor is held by the FileBlockCache. This object buffers data
passed to it in memory, and defers writing of said data to another thread. I
added the async wait for the file descriptor to be inside that async "defer to
other thread" step.
This means that while the content process is waiting for the file descriptor to
come down from the parent process, we'll buffer media data being streamed in
memory. Given that our MSE implementation will buffer up to 100MB of media data
in memory anyway, it seems that more buffering in the src=url case while we
wait for an async IPC to do a round trip to the main process is acceptable.
MozReview-Commit-ID: 3OTBTWw5pr0
--HG--
extra : rebase_source : 56e0a1f1473db3c9722330254f7a4bf3a1f5caa3
So that we can write gtests easily at next patch.
MozReview-Commit-ID: 8ZWVYO1hDOW
--HG--
extra : rebase_source : 8c3523b06fe284376d59914ecfa3791a91930fc2
Move the creation of MediaElementGMPCrashHelper out from MediaDecoder.cpp
which reduces the dependency of MediaDecoder to HTMLMediaElement.
MozReview-Commit-ID: E60aMfcFr7V
--HG--
extra : rebase_source : f50a8ee6f2fbec0bdf117eb1217066bc9c701745
extra : source : dd4e52da6d0d6205fe61d0caba44bbff008fd21a
ConstructMediaTracks and RemoveMediaTracks are actually HTMLMediaElement's responsibilities.
MozReview-Commit-ID: 8lOdzD4pN7N
--HG--
extra : rebase_source : 7159d2c62b77429e5b2305b9e3eb7a0020a3b52c
extra : source : 0467c059be3cd8f066da5fc912b7738a5b9c4dd9
Open a GetOwnerDoc() method to the MediaDecoderOwner interface and then we can get the
owner document via a pointer to MediaDecoderOwner in MediaDecoder.
MozReview-Commit-ID: JCzQDLx1MsU
--HG--
extra : rebase_source : e194c95cb1513046ec7aa19d6c6e9f8231971a2d
extra : source : 1b9c45911a036e3677b6636cda84a636681d71de
Instead of calling DownloadSuspended() via a pointer to a HTMLMediaElement,
we should call DownloadSuspended() via a pointer to a MediaDecoderOwner.
MozReview-Commit-ID: BvExQuchsWb
--HG--
extra : rebase_source : 0c8a5d412e91e2c370050a4706fc6f2afc0c20e9
extra : source : fb5ca26fc018e273296411a037b70b922cb26f4d
It is a regression of bug1307710, if something wrong during the ConvertCueToDOMTree() in vtt.jsm, we will get null ptr.
MozReview-Commit-ID: LSQrJIhBzRU
--HG--
extra : rebase_source : b0a2cf675f9288ddc9c264faaffcf97049c6c1c6
The assert in bug 1334421 mentions the MOZ_COUNT_{C|D}TOR macros, but the same
comment seems to apply to the NS_LogAddRef that's part of the
NS_INLINE_DECL_THREADSAFE_REFCOUNTING macro.
This fixes it for me.
MozReview-Commit-ID: CPjdO8YBbt0
--HG--
extra : rebase_source : 5833c4165517addd3f48f0d7dfe196cec494b013
MediaCodec doesn't take any input after EOS unless it is flushed.
MozReview-Commit-ID: LoHlN753e8J
--HG--
extra : rebase_source : 5a051cef2f4afb3357e2756d1f0f2f3ae741295c
Under some circumstances, and seen on Windows 8, a decoded sample can be returned without the MFT returning MF_E_TRANSFORM_STREAM_CHANGE.
For historical reasons, we required that message to be returned at least once to set the output image size. This was required as the decoder used to be recycled with different video streams.
This is no longer the case, we can rely on the video info instead. It also greatly simplifies the code
MozReview-Commit-ID: H14KBiNWrjQ
--HG--
extra : rebase_source : d098f884127bc95e3ca4363bf3d0cdda6d3bd771
This means the EME PDM implementation can safely tell when a CDMProxy is a
ChromiumCDMProxy, so we can create an appropriate MediaDataDecoder for it (in
the next patch).
MozReview-Commit-ID: CpL6QRa7SwJ
--HG--
extra : rebase_source : 3821c378c73067066f3cc67499680bdf546fb4f0
This ensures that when we're using the ChromiumAdapter that we actually ask it
whether it'll work, rather than asking the adapter we're not using.
MozReview-Commit-ID: 85nZPl9MdWa
--HG--
extra : rebase_source : 90de89bec9b004859c3c2c09ed8efbd255acc141
We still use the same EMEDecryptor MediaDataDecoder as is used by the existing
EME decrypting path.
MozReview-Commit-ID: 3pXPjChctLb
--HG--
extra : rebase_source : 67575a02290ddb871510dd88f59fdab77658b3ce
This means the MediaKeys is able to create a CDM.
MozReview-Commit-ID: 94Xc7sCLhH3
--HG--
extra : rebase_source : 914db1f04e0770776ae25c7b8bdc59e729fe78d0
Otherwise navigator.requestMediaKeySystemAccess() doesn't know whether we have
a CDM or not.
MozReview-Commit-ID: Hic6UneGA4u
--HG--
extra : rebase_source : 68ce766bede0f5c8e41de3a3f9e46b6ef88cab96
This will eventually replace GMPCDMProxy. Methods will be implemented in later
patches.
MozReview-Commit-ID: 86pwo81tFZv
--HG--
extra : rebase_source : df41a20a0fefaf26a63ed18f1ccdf7fa5a3a1e89
We currently use an adapter object to adapt plugins that don't conform to the
GMP interface to the GMP interface.
We use the WidevineAdapter to talk to the CDM from the two GMP IPDL protocols.
We will be using a single protocol to talk to the Chromium CDM, so we need a
new adapter which handles that.
MozReview-Commit-ID: F7hnZ9oo9mJ
--HG--
rename : dom/media/gmp/widevine-adapter/WidevineAdapter.cpp => dom/media/gmp/ChromiumCDMAdapter.cpp
rename : dom/media/gmp/widevine-adapter/WidevineAdapter.h => dom/media/gmp/ChromiumCDMAdapter.h
extra : rebase_source : 7c08edea3c11d41eb3ecfa9c7a8ef65cf3b8ddb0
Infrastructure necessary to create an instance of the CDM process.
MozReview-Commit-ID: 7oQ86x6BNWj
--HG--
extra : rebase_source : c725a958c507b7f93ce9cfccc475f259ae9ccbc2
We currently do two sync IPCs to launch a GMP; one from content to main process
to get the nodeId and a second to get a GMPContentParent for that nodeId.
We use the nodeIds to ensure that the GMPVideoDecoder and GMPDecryptor actors
correspond to the same CDM instance/process. However once we switch to having
one protocol that encompasses both decryption and decoding, we don't need to
worry about making sure our decoder and decryptor actors match up, as we only
have one underlying connection to the CDM instance.
So we can merge the get nodeId and get GMPContentParent operations into a
single operation that does both. To do this, we just need to pass the
parameters used to calculate the nodeId in the LaunchGMP message.
Once we've switched EME over to using the CDM via a single actor, we can remove
the nodeId nsCString from our media code and from GMPVideoDecoder and
GMPVideoEncoder.
MozReview-Commit-ID: 7GXlJ37fOTZ
--HG--
extra : rebase_source : cf20a165048f777f34dab01fce984018ad641b85
The implementations of this protocol will be stubbed out in later patches.
MozReview-Commit-ID: 622CB1BOoR9
--HG--
extra : rebase_source : b796bfb4c0d0d2872787043e3b9fc83a0e6b09ea
This adds 'media.cubeb.backend' to ContentPrefs, which is necessary because
`cubeb_init` is called _very_ early in the lifetime of a content process,
because it needs to be called before enabling seccomp.
If OOM happends, just return null and the DummyMediaDataDecoder will reject the DecodePromise with NS_ERROR_OUT_OF_MEMORY.
MozReview-Commit-ID: H6sTyoQWZk5
--HG--
extra : rebase_source : 5046a68978b817db8f1191e1f56e80ec5848899c
An interesting intermittent condition not previously handled.
We were incorrectly assuming that we always had a decode promise pending when a drain was requested.
If a change of content occurred when resuming from a waiting for data condition: we would have stalled forever as the waiting promise would never have been resolved even after new data was appended.
MozReview-Commit-ID: BQSRSHYqTSe
--HG--
extra : rebase_source : e091969ce35728cd3ded40161eaaa117df2c6886
https://hg.mozilla.org/mozilla-central/file/34c6c2f302e7b48e3ad2cec575cbd34d423a9d32/dom/media/MediaFormatReader.cpp#l2835
NotifyDataArrived() is dispatched again if |mNotifyDataArrivedPromise.Exists()| which will then be dispatched again
recursively until mNotifyDataArrivedPromise is completed. This is a waste of CPU cycles.
We can use a dirty flag to note we should update buffer ranges again when the current update is done.
MozReview-Commit-ID: 6hInhGKnXJE
--HG--
extra : rebase_source : 71aa2c16112428c34def094515e37aa1f028a3fc
VideoData doesn't care what's in aInfo but display size and aPicture are unused.
MozReview-Commit-ID: IBqq8Rm8dM4
--HG--
extra : rebase_source : 10e2390f87925ef9179d28d86240f68a35c6c6d4
Spec (being written): https://github.com/WebAudio/web-audio-api/issues/1139
Bug 1343550 - Prevent touching promises when shutting down an AudioContext, when the global is going away soon. r=baku
MozReview-Commit-ID: F6en9KEbNNf
--HG--
extra : rebase_source : 212968cb3ed9afc1e6598946e54316e54762d0d0
Note the race is uncovered by P1 which kinda change the order of events.
MozReview-Commit-ID: 3INYvJVUhSG
--HG--
extra : rebase_source : e378c2a437a5a729008d39570be2a9087a7eb5f7
extra : intermediate-source : 02e2ecfea068dd9f487791287064e684a15dd599
extra : source : f2f40c70a2304e3e499422f3a7c46b59b54ad1ae
So that the we can listen to the 'canplay' event in the videocontrols.xml.
MozReview-Commit-ID: 5T7akeC7EJq
--HG--
extra : rebase_source : c9f932e021fc7939dc8558813a1a974753a968ec
We never suspend videos that is NOT in-tree because we found that, according to the Telemetry data, most (>70%) videos
which are used as the argument of drawImage() are not in-tree. So, by preventing suspending not-in-tree videos, we should
be able to alleviate the pain of not able to resume video decoders synchronously.
MozReview-Commit-ID: 8eqs0pHZLIt
--HG--
extra : rebase_source : 964c0047753696cad2e40bcf74c2b8ee9faccdea
extra : source : 93c38caa15b1a29f8f1e8e6d3a5e859f97bc1aae
Initialize the MediaDecoder::mIsElementVisible to be "!aOwner->IsHidden()" at the MediaDecoder's constructor is wrong.
Insted, we initialize both MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible to be false at the construtor,
and then assign the HTMLMediaElement's real values to them at HTMLMediaElement::FinishDecoderSetup() via the the MediaDecoder::SetActiviyChangesToDecoder().
The initialization values of MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible (in the constructor) do not matter because the valuse are
not read untile the first MediaDecoder::SetActiviyChangesToDecoder() method call.
MozReview-Commit-ID: Cdovq5pG9Nv
--HG--
extra : rebase_source : 91f3b4c2515124b4c195dd246bd9b404178a35de
extra : source : 81b5e89a5bd20f37b8c3daa1230db30808026ff4
Make HTMLMediaElement no longer has logic of deciding visibility, it just passes all information into MediaDecoder.
MozReview-Commit-ID: ApVcEQfboO
--HG--
extra : rebase_source : 88c70b0cf1933d9cf814359909463a811be2ab9f
extra : source : 669d1340d3c93d3e0eab55ce87693f842cf40247
If mHasSuspendTaint is set, the mVideoDecodeSuspendTimer should already be canceled
so that HandleVideoSuspendTimeout() won't be invoked.
MozReview-Commit-ID: BGwSucZtH4d
--HG--
extra : rebase_source : a7038309846365cb3905aa193b25d103812a9200
extra : source : 28ca96e1622d7f3af427c90f7b4a2bbc58b81ce8
The role of MDSM::mIsVisible and MDSM::VisibilityChanged() have been replaced by
the MDSM::mVideoDecodeMode and MDSM::VideoDecodeModeChanged() completely.
MozReview-Commit-ID: 8sW0s8ilF1E
--HG--
extra : rebase_source : 20f4b0c2e5a34018b3189b4d10dd55e68881c0e7
extra : source : 2eba9a76da70749583125176e8b7c6c959b74d38
So, the MediaDecoder is the one who rules out the policy of suspending video decoder.
We also extract all the policy rules into one single method, MediaDecoder::UpdateVideoDecodeMode().
MozReview-Commit-ID: IOQq6kFfkIs
--HG--
extra : rebase_source : 3d92c63aed2545391c45cdd7c1236d5df0b8d2f8
extra : source : 9c6c5f22d25171a206e828faa2c7c91d47f748f1
The MDSM::mVideoDecodeMode and MDSM::SetVideoDecodeMode() are merely a renaming of MDSM::mIsVisible and MDSM::VisibilityChanged().
However, the renaming explicitly reflects that MDSM provides mechanism only without participating in the policy decision.
Will reremove the MDSM::mIsVisible and MDSM::VisibilityChanged() in following patches.
MozReview-Commit-ID: JdMKQTgVCf3
--HG--
extra : rebase_source : 95977b205f235b6a456d12dfde93fe84f3b12aa7
extra : source : 4382a3c10f30653d5a70abb3bd4b8146a4272784
Once part 4 is applied, a suspend video element won't be rendered anymore, so that the video element keeps the last decoded-frame.
By this way, drawing a suspended video element to a canvas should get something that is not single-color.
MozReview-Commit-ID: J6dsZIvtO
--HG--
extra : rebase_source : 247db68d5fb0f6b24b07c197411e5d423ff02705
extra : intermediate-source : 145a223ab9777edc2bc9f2868eef2cbcd8725171
extra : source : 7e55644b5ba79c7a13211c23cedc5dc77a1e55ff
The blank decoder used to create green frames.
Bug 1274626 patch 2 modifies its behavior to return black frames.
The original implementation is better in memory usage, so we revert it.
MozReview-Commit-ID: Lue63Rsoy3G
--HG--
extra : rebase_source : ba6a1bb74a2b5d61b245c114e4dd5cf32dc29b89
extra : intermediate-source : fcb4f38cf4d4ee2709a3d0d4e2945eef9dc6cab0
extra : source : e920b71a11ebf410f4a1c99708911be98f68586c
So that the suspended video element won't be rendered any more and keeps the last decoded frame.
This is the effect that UX specification defines.
And actually, we don't need to set ImageContainer if there are no valid new images.
MozReview-Commit-ID: B7RS3LXu8J0
--HG--
extra : rebase_source : 114d68046cbbb478fda63d16da7fbb4fa2fc3dd3
extra : intermediate-source : 29e6d114dfb0c64d0b6a77d924066be9f69bb287
extra : source : d6a2b47b14f6ac00ea420f5eba7190c7af725381
The video decoder of NullDecoderModule returns a VideoData with dimension of zero size and no image data.
By this way, we reduce memory usage while a video element is suspended.
MozReview-Commit-ID: IMODFOGdpaj
--HG--
extra : rebase_source : e12dc91158939052b23d4ab9707485bb3565dc41
extra : intermediate-source : f8390b1c52e9ee859c33b7a9d2e34781534eb3ff
extra : source : 8a002d74db6c445dff17aa24d2e92f9c27019b07
Change name to 'Dummy' to signify it's base for decoders that don't decode.
And we will implement a new NullDecoderModule in the next patch which will utilize the DummyMediaDataDecoder.
MozReview-Commit-ID: LPsczoztgx3
--HG--
extra : rebase_source : 413345139ba060065217cfd7718665091f8f6166
extra : intermediate-source : 12d022e15b7a3a91867293fd2e71510fa084ff02
extra : source : dec60f61cc8809ebe6dd65cb16a325f2272b3ce2
Some uses of media elements should 'taint' the element so that the video doesn't participate in video decode suspending.
Add the infrastructure to track the taint status on MediaDecoder and mirror the status to MediaDecoderStateMachine.
MozReview-Commit-ID: Ik6aDIzrZaO
--HG--
extra : rebase_source : 31fdddabdc62cb8c59db19c1f466f674ef503ee8
extra : intermediate-source : 906cb039bea3e5ac6c1ec852209db28be60ba201
extra : source : 1ac0f1b9264706f65e04528757bd60028331d31f
NS_DebugBreak truncate all output to 500 characters.
MozReview-Commit-ID: 1gEyJNge7gk
--HG--
extra : rebase_source : 0996ef25dd14cc8f5fe03672d85d37cfcc3ab14a
Alfredo.Yang
JW Wang
Chris Pearce
Paul Adenot
Florian Queze
Gerald Squelart
Wes Kocher
Ben Kelly
Nicolas Silva
Carsten "Tomcat" Book
Iris Hsiao
Alastor Wu
Paul Bignier
Jean-Yves Avenard
Kartikaya Gupta
Kaku Kuo
Andrea Marchesini
sotaro
Boris Zbarsky
bechen
Bob Clary
Sebastian Hengst
Ehsan Akhgari
Jan-Ivar Bruaroey
Kevin Chen
Andreas Pehrson
John Lin
James Cheng
Matthew Gregan
Damien Zammit
David Major
Bas Schouten
Frederik Braun
Randell Jesup
Munro Mengjue Chiang
Nico Grunbaum