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
