In a parent process, the temporary file was created and opened by calling
NS_OpenAnonymousTemporaryFile() from Init, which was called from the main
thread.
In addition to being called at least once when the first media file is fetched,
it may also be called if caches need to be emptied.
So it should help to move this operation on the FileBlockCache thread, if only
to remove potential background-hang reports from non-e10s configurations.
MozReview-Commit-ID: CjPsHEsL3Ch
--HG--
extra : rebase_source : beaa2793dea82d853669d87c9434139d88562da9
SetCacheFile, Init, Close, and MoveBlock all had NS_IsMainThread() assertions.
However they all use Monitor's to access member data, so they should be thread-
safe.
(Upcoming patches will actually start using some of these functions from non-
main-threads.)
MozReview-Commit-ID: E1auNEXuoF9
--HG--
extra : rebase_source : 41af7d16f8a9bde5492e864712981a208f3b47be
The current call flow ensures decoding metadata only happens at most once
and therefore EnqueueLoadedMetadataEvent() will only be called at most once.
We don't need the mSentLoadedMetadataEvent flag.
MozReview-Commit-ID: E95jtRrKupw
--HG--
extra : rebase_source : b95887154a2392ca5a6fcb45b4c2dad60fb65b70
This works around an Android 4.2.2 bug that reports incorrect sizes for hardware buffers.
MozReview-Commit-ID: 4rAu8d1RwOJ
--HG--
extra : rebase_source : f63ad96427b90dc24e0cb84319f256d1ec354b5e
Now the fragent mp4 is seekable, so we should remove "street.mp4" from unseekable test.
MozReview-Commit-ID: 9S18yj7rOjA
--HG--
extra : rebase_source : 12e01834df75257c0999aa186c1a825c7b13af48
The duration is rounded down to 0 if |frames| is smaller than |mInfo.mRate|.
We should call FramesToTimeUnit() instead.
MozReview-Commit-ID: E7eOQuD48x2
--HG--
extra : rebase_source : 1edabb9a9fe495f89a13df71d73d3b9aef49fa9d
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
This was working because of the unified build, but passing
--enable-av1 changed the source partitioning in such a way
that the referenced defines and symbols were no longer available.
MozReview-Commit-ID: CRjyhLtOhoM
--HG--
extra : rebase_source : bce3810fcff39669c4578f1b545fb619be691e38
Now we don't support flac on fennec, only need to test it on non-android platforms.
MozReview-Commit-ID: 9Qli9zSlNe9
--HG--
extra : rebase_source : 4cc96bc25d499b27f745b20e5ca8bb961a4632dd
Will also significantly speed up sniffing in general as this code is called quite often.
MozReview-Commit-ID: KLjpRwynv2J
--HG--
extra : rebase_source : 2b0b652ab8f8e856cb5e7e755ef62480c6b7d281
Defer determining whether we have usable decoders to an off-main thread in
order to avoid janking the main thread.
MozReview-Commit-ID: Ape5zEBBMrz
--HG--
extra : rebase_source : 1b77046ebb7bb2d4ff1ba53afce904d3de45c335
After changes from Bug 1358224 to add test-related RID filtering, we no longer
need the test-related SSRC filtering (which only partially worked).
MozReview-Commit-ID: 4A6slqOTjbU
--HG--
extra : rebase_source : 6e36e4fdaab46b44fadadd7f55eb60c6c89ac106
Since RefPtr<T>&& can't be converted to T* implicitly, we need to change
T* to RefPtr<T> in resolve/reject callbacks to make it compile again.
We should review the changes later to look for the opportunity to
optimize away unnecessary AddRef/Release pairs.
MozReview-Commit-ID: 22rHQ8dhxJv
--HG--
extra : rebase_source : 1b09f353d6e86d60c93a2746333585ec0dba8526
The MP4Reader class was removed in bug 1163486, replaced
by MediaFormatReader combined with MP4Demuxer. Bug 1175752
disabled the corresponding gtest, but as the underlying
object is gone, the test should be removed instead.
MozReview-Commit-ID: 7mU4Q98LtKA
--HG--
extra : rebase_source : 10b20e749321a50bac708c493badbdf32b41f859
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
"video.controls = false" will remove the binding of videocontrols which is a xul element.
In vtt.jsm, we need to remember the last show/hide status of videocontrols, then render cues when status changed.
MozReview-Commit-ID: 30rebAuqmxy
--HG--
extra : rebase_source : e011ec0679ab03071e01b91c124c5b72e481a8da
Turns out that Chrome treats the robustness values as SW_SECURE_DECODE to mean
that SW_SECURE_CRYPTO is also supported. So we'd better follow suit...
MozReview-Commit-ID: 6J68IsSQhyL
--HG--
extra : rebase_source : 08baf83f0812f52670f1643e7e86ced0a0972f64
AddBlocker() could fail during main thread shutdown. We should clear sInstance
on failure so next Register() calls can fail gracefully.
MozReview-Commit-ID: KiRRhO9ymbf
--HG--
extra : rebase_source : ed514f71f85c3d2f7ed6a8ee6f701ae131ec5962
extra : source : 1f379bcfc15b77cc89ee7a3a9e12e85f63a83524
Resetting decoders somehow cause the WebM demuxer to seek and initiate
network download which is blocked by the site for invisible media elements.
See comment 5 for how this blocks playback.
We work around this issue by not resetting decoders when entering dormant
since we will reset them anyway during seeking when exiting dormant.
This change is a workaround for this bug though. However it is also an
improvement for the dormant state in general since it removes unnecessary
works to improve performance.
MozReview-Commit-ID: KtbpQlrO8J
--HG--
extra : rebase_source : 6e773879126ed447fdceb565d3fffa3b546b4a48
Currently we call HTMLMediaElement.canPlayType() in a JS function called
shortly after startup in order to collect telemetry as to how many of our users
don't have functioning decoders.
Unfortunately, HTMLMediaElement.canPlayType() checks whether we can play a
codec by instantiating a decoder, and this requires us to load the system
decoding libraries from disk. This requires disk I/O, which can cause jank. We
have some BHR reports showing that canPlayType can hang for > 8 seconds to back
this up.
So move the collection of this telemetry to an idle service observer, so that
we only collect this when the user is idle, and do it on a non-main thread so
it is less likely to cause jank.
MozReview-Commit-ID: HJQawmRxz
--HG--
extra : rebase_source : f5a8596fd9de770abd20e1a3e8ac0bcbb5b48599
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : dff76a1fa604962b45446d632ffb4da58853cfa0
Call AOMDecoder to handle AV1 video tracks from the WebM container.
The new decoder is very similar to VPXDecoder so we can use parallel
calls. This codec is still build-time conditional.
MozReview-Commit-ID: 5cexCZiNBqo
--HG--
extra : rebase_source : 992687c0d589bef75b6b77a1cc4137d61267472c
Conditionally enable the AV1 decoder as part of the
agnostic PlatformDecoderModule factory.
MozReview-Commit-ID: ApZ1CMvdLE
--HG--
extra : rebase_source : 33cedc6bd6243ccd2019ea40dc9b989921c63b98
Port the VPXDecoder interface to libaom which uses
the same api with the names changed. I've removed
the alpha support for now.
MozReview-Commit-ID: IdxcVWhNgVl
--HG--
extra : rebase_source : 5f3a84fb9a827f01c80057eb520bde184c41f0b9
We don't want to trigger download when calculating buffer ranges since download
changes buffer ranges.
MozReview-Commit-ID: Be8qFUQ5PpR
--HG--
extra : rebase_source : 4fd77e031577332d9d112faef869cd935275b1af
The crash happens when:
1. there are multiple <source> children.
2. decode error happens on the 1st child.
MozReview-Commit-ID: 60UXaQ475Nh
--HG--
extra : rebase_source : b7e61ae909cfa10fb2db3c41b278449de41b9450
This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.
MozReview-Commit-ID: H0gF3FqZsU6
--HG--
extra : rebase_source : 3886b757f3476060067811dcb385967769a67023
This was working because of our unified build, but having
the correct definitions for all types used by the header
helps editor navigation tools.
MozReview-Commit-ID: LuWEeTIikla
--HG--
extra : rebase_source : 0046ec17ac45270adc771bd0cf77c8381f99737b
This moves those two functions from a single test to a VideoStreamHelper in a
common file, so they can be used when checking video flow in multiple tests.
It also implements a VideoFrameEmitter that provides tests with an easy to
access video source where VideoStreamHelper can verify flow on the sink.
MozReview-Commit-ID: Fin9eiVmBe
--HG--
extra : rebase_source : 8b62124b0182d7e7bd78788e031b2d2259db9e57
This was used only for B2G, was proprietary, and is causing issues, because
`AudioContext` can now have a parameter that is a property bag, per spec
(although we haven't implemented it at the moment).
MozReview-Commit-ID: 6LOlNp0cbfV
--HG--
extra : rebase_source : 48aa342213dba201c1062a08c7453acd16b8baea
This allows more use of the implicit version of InvokeAsync() without specifying the storage types explicitly.
MozReview-Commit-ID: 40WisaVX8Jy
--HG--
extra : rebase_source : ba34515788f0bc8264fac9a6897e234966d8b762
extra : source : b651963fe562755c0b2998ae6a95ffad400060ad
Use the new helper functions instead of calling libvpx directly.
This simplifies adding other codecs in the future.
MozReview-Commit-ID: 8VX0d5S50EE
--HG--
extra : rebase_source : 34be2118bc5d1bfcb6237d7fbe67d8fbc5ef1508
Encapsulate code from WebMDemuxer to query keyframe and frame
resolution inside VPXDecoder, so we have a clean wrapper for
all the libvpx functions we use.
MozReview-Commit-ID: ASRRhNl0A41
--HG--
extra : rebase_source : e0a27e946a60e0c33ecf4908f1e09436f836e123
Use the enum we already have here instead of converting
to an int when we pass it around, giving us better
type checking.
MozReview-Commit-ID: Gj4xmtQnzw2
--HG--
extra : rebase_source : fc7769c9650c59f52bfd8611e6cabb8e5b6d7068
This simplifies the comparison and update logic.
MozReview-Commit-ID: A6YII8tlEUn
--HG--
extra : rebase_source : e225b34f91e12591d5872121e024ef29c63a11e0
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : 4ad324f6bb1be637da584f323a3e039c5b4f664d
StoreCopyPassByRRef<> ensures a copy is stored in the runnable.
We don't have to worry about the concern of bug 1300476.
MozReview-Commit-ID: DHqlzlVLBFV
--HG--
extra : rebase_source : 77f2175611aa6fad88207a771de75fd28fd46f21
extra : source : 429c62928fd43185da45c905a150cfbe84cb3cf7
We avoid passing event data to the listener function to save copies
if it doesn't take any arguments at all.
MozReview-Commit-ID: 7Hkzxrluemm
--HG--
extra : rebase_source : 22b894a58e2bc3836d37b7fd6aaa1f09d82eaeee
extra : source : 67a57b8eaebd355f73b0f10fb99afeaf2ccdb89e
Note this breaks the MediaEventSource::CopyEvent2 gtest since there is always
one copy or move when storing the event data in the runnable created by
NewRunnableMethod() even when the listener function takes no arguments at all.
We will fix it later.
MozReview-Commit-ID: J9T63yxXko2
--HG--
extra : rebase_source : f15fa78129e562fb3a65027114095b205791d4c7
extra : source : e734b4d950c415be18e2fbc30e26e617758aa556
This is needed by P2 where |Listener| must be ref-counted so we can use
NewRunnableMethod() to pass event data to the listener function.
MozReview-Commit-ID: CpAgOmxcijc
--HG--
extra : rebase_source : f80a302788f6312a912d710262322b30b2bce4c0
extra : source : 4ce544aacca4897bc3d2bb25fd415df93dc940b4
It turns out that sync notification is a bad idea which is easy
to be misused and could results in unexpected reentrant call flow.
Since it has no users after the mass media code refactoring, it is
good to remove it now to prevent future users.
Backed out changeset fb5b05298007
Backed out changeset 9e1fb308cf51
MozReview-Commit-ID: 9WGvRCbvJhQ
--HG--
extra : rebase_source : 748cae9449636c68f3fffbaed0e08347fe63cd91
The simulcast mochitests setup the receiving PeerConnection to receive
simulcast video streams which Firefox doesn't really support. Without
a test media server, this is about the best we can do and still test
simulcast.
Unfortunately the two simulcast streams arriving with different ssrcs
(as expect) exercises code we have to deal with some services switching
ssrcs midstream. In the tests, this causes intermittent failures
because the test is waiting to receive a certain ssrc, and the receiving
VideoConduit has switched to the other ssrc.
This change adds the ability to filter on RID at the MediaPipeline level,
which we can setup prior to media flowing. This avoids the ssrc switching
issue since the VideoConduit only receives one ssrc until we change the
RID filter to the second RID. At that point, the VideoConduit sees a new
ssrc and the switching code works as intended.
The modified mochitests setup the RTP stream id header extension, and then
filter on each of the RTP stream ids in turn.
MozReview-Commit-ID: KApfaxMX8rl
--HG--
extra : rebase_source : d7ae88d9675acd7b3700f342ca6a68d0bbb0ced5
The simulcast mochitests exhibit an intermittent failure due to ssrc-based
filtering that can be solved by filtering by RID. The RTP header parser
used in MediaPipeline also needs to have the RID RTP header extension
specified in order for it to properly parse the RTP header and allow
filtering on RID.
MozReview-Commit-ID: E54HCGLVYDk
--HG--
extra : rebase_source : b53085f23cb6558611aa7622f55637e19439c9c3
The ChromiumCDMParent is informed of the shutdown of its plugin, so we can
use that to inform the CDMProxy that its connection to the CDM has been
severed. This means we shutdown cleanly if the browser closes while playing.
MozReview-Commit-ID: HphQ2exu1gj
--HG--
extra : rebase_source : ff9ee3699915e8b7527570e839eb3bb0a0ab46bc
We are pre-allocating shmems in the content process for use by the CDM in the
GMP process. We guess the size of shmem required. However if we guess wrong,
currently we always end up taking the non-shmem path for video frames to
return to the content process, which results in us sending another shmem
(of the wrong size) to the CDM, and this continues until we hit the limit
on the number of shmems that we tolerate the CDM asking for.
So in this patch, I change our behaviour to detect when we're allocating
shmems that are too small, whereupon we purge the existing shmems and switch
to allocating them at the size being requested by the CDM.
This means we recover from incorrectly guessing the size of shmems required
by the CDM. The overhead of an incorrect guess should be one video frame
transferred via the nsTArray path.
MozReview-Commit-ID: 8o1s7FI2UBd
--HG--
extra : rebase_source : 0612d199686278612e8c58dc97e96a9304ea3ee9
So we can cancel the bad test as soon as possible and give a better description about the error.
MozReview-Commit-ID: ExKIK2HqJkN
--HG--
extra : rebase_source : 26391dfea33ab792cc5f0dc58fa42e6309e0c699
extra : source : 138125800895658a6feb88e3f90487d62b955f6a
We can remove AbstractMediaDecoder::UpdateEstimatedMediaDuration() which
has no callers at all.
MozReview-Commit-ID: Eub12jQ25KK
--HG--
extra : rebase_source : f564b84a147252bd98c13fe475af971808880c8c
extra : intermediate-source : 4c0870a71b2091c39f5fc67c5cf21dea0a4cc459
extra : source : 1bfe40324a3801f8d60384b247d85f04b8971bbe
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: K3Bz3uEXLDK
--HG--
extra : rebase_source : ade3cbd61c764b73a22c360572a525127dbadbc5
extra : intermediate-source : 013227a4aa645fc34a82c44130db6c847d74960b
extra : source : 1ab7ce426b557e4ce9979e023f9e84b4690eeaaa
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 4beba0212411a0f5867feb506bbf732f5a934fa9
This in large does the following:
* Changes the model in MediaManager to align with that of chrome code, namely:
- One GetUserMediaWindowListener *per window*, containing N SourceListeners for N gUM requests, and
- GetUserMediaWindowListener replaces GetUserMediaStreamListener
- So if two SourceListeners stop we can still send only one event
* Breaks a special event specific to B2G chrome
MozReview-Commit-ID: 3wbPFmc9yWj
--HG--
extra : rebase_source : 4ad324f6bb1be637da584f323a3e039c5b4f664d
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: LRz9d4yKBYJ
--HG--
extra : rebase_source : 1f73f1f338142b3183491d04726821a881ccabbe
extra : intermediate-source : 88e167b7b06303d10d92cd5317502f405d1c553e
extra : source : 98deb30ec93d395f9951f5fc488170ae35e29675
1. The 'onlyLoadFirstFragments' flag is not used anymore.
2. The 'noEndOfStream' flag is never set to true.
3. EMEPromiseAll has no callers.
MozReview-Commit-ID: BH3r5AvMOSN
--HG--
extra : rebase_source : dbe002d18d448d63e5b9e869f194cfbb54a498f8
extra : intermediate-source : d6a8bf58e8e29e726986d0c8e6159231dfe8aac4
extra : source : 5a899425c326ff63365a99e314a728e6a0125a7f
Note we don't need to pass the 'onlyLoadFirstFragments' flag
since we ensure the test won't finish until LoadTest() is resolved.
MozReview-Commit-ID: 2cFDGhqWkrP
--HG--
extra : rebase_source : 6c647f2238e9a73297c8ec449a965129e9ad47db
extra : intermediate-source : 8562a1de41a9ce008f862611a31c4f1f014e891d
extra : source : 1aaad490dc44b9a33c92e724dedf4d4ca600febb
The attributes are used by MaybeCrossOriginURI() which is called by LoadTest() indirectly.
MozReview-Commit-ID: LH2STpONuCE
--HG--
extra : rebase_source : 5762de80943d30064df0d4a69ebe7d36a12f308b
extra : intermediate-source : 73e455a974c9bc3609b72d3ffbbcbc6f1077f62b
extra : source : 7802185d9bcaec4f7377de94e4876d995a8ab019
Use the new helper functions instead of calling libvpx directly.
This simplifies adding other codecs in the future.
MozReview-Commit-ID: 8VX0d5S50EE
--HG--
extra : rebase_source : c870b32bac6b924188dd722c052fb88156ad96c8
Encapsulate code from WebMDemuxer to query keyframe and frame
resolution inside VPXDecoder, so we have a clean wrapper for
all the libvpx functions we use.
MozReview-Commit-ID: ASRRhNl0A41
--HG--
extra : rebase_source : a1421462f6fc66a2abd965782ec408a8bcf7fe1f
Use the enum we already have here instead of converting
to an int when we pass it around, giving us better
type checking.
MozReview-Commit-ID: Gj4xmtQnzw2
--HG--
extra : rebase_source : 95f582e655f1a942dfb68cbba588c44afbb8a38f
This simplifies the comparison and update logic.
MozReview-Commit-ID: A6YII8tlEUn
--HG--
extra : rebase_source : ddf4304298209e515eb44962e8bc9ccd38c9956f
nsInputStreamPump should use the stream as nsIAsyncInputStream if available.
In order to do so, we need to wrap a BufferedStream around it.
MediaResource cannot use a simple sync nsIInputStream when BlobURL are involved
in the content process.
There was a race where ending the track before removing the direct listener here,
allowed the source to append more data (notifying the direct listener)
after the consumer had been notified of the ending track.
MozReview-Commit-ID: E08UeMNQhGx
--HG--
extra : rebase_source : 740c4fde40b9e19974922cd893618032c683493d
There was an indirect race from destroying this MediaInputPort before removing
the direct listener.
MozReview-Commit-ID: 7rPzsLL4EvG
--HG--
extra : rebase_source : 6271778593079609119153ce8b81587a9188d8ba
block->mOwners might be empty if all streams for the resource id are
closed. We don't bother write the data to the cache since there is no
stream to use it.
MozReview-Commit-ID: KKiyZqLBjim
--HG--
extra : rebase_source : 7fa0a6d841dff91dd7142aac5a336b950342ac67
1. using media::TimeUnit to save some typing.
2. replace TimeUnit() with TimeUnit::Zero().
3. replace TimeUnit::FromXXX(0) with TimeUnit::Zero().
4. replace TimeUnit::FromMicroseconds(std::numeric_limits<int64_t>::max()) with TimeUnit::FromInfinity().
5. replace some uses of int64_t with TimeUnit.
6. replace t > TimeUnit() with t.IsPositive().
MozReview-Commit-ID: 6hC94PXx86i
--HG--
extra : rebase_source : 1ea3b409e6ec12915f3e1a00359d6ff4152c8917
extra : intermediate-source : e31a12ad0e7a4840119036f261ed17eaaff85734
extra : source : ae07ee48000c4a52da0e4fd502b4d690ec51ce1f
media::TimeUnit can take its place. We don't want 2 things for the same purpose to cause confusion.
MozReview-Commit-ID: 3z6hbgXFsxP
--HG--
extra : rebase_source : 0b472e351abdc48e337aaf645ae8be467e8a300f
extra : intermediate-source : 4e2156ec04fd30af6cf59adfd1390cf67f411d4c
extra : source : bf5b035c7041a892517373dd566d2a7d7ec60c72
