mManager would be accessed in both main thread and task queue, and be set on task
queue, so we need to make sure it's thread-safe.
MozReview-Commit-ID: m76KeEsDgB
It would only be accessed on task queue now, so we don't need to lock it.
MozReview-Commit-ID: 6jd36TQW4aA
--HG--
extra : rebase_source : e8bb53a226154312496149ab8f6b00dead49a3b6
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
CreateDecoder is the only caller of InstantiateDecoder, and all CreateDecoder
does is call InstantiateDecoder.
MozReview-Commit-ID: KwwL2el8L4x
--HG--
extra : rebase_source : bff225558fd2de535c2cb010eb35b95c6d9469e5
Replace with conditional compilation enabled for Linux targets.
MozReview-Commit-ID: GjD0Ix8aeJW
--HG--
extra : rebase_source : 18dd93eda0a9ebc1846a876caa4f5d27d8b75909
Adding partial support for 10/12-bit video images seems to have
broken the native pixel-stride support we were using to pass
8-bit AV1 frame data formatted in 16-bit pixel values, resulting
in vertical green lines.
Revert to the earlier behaviour of always downsampling to 8 bit data.
This is slower for the demo stream, but at least displays correctly.
MozReview-Commit-ID: 8kSd9kph9DE
--HG--
extra : rebase_source : 040795b4d99a2001397c0021f34d39535aa4aa2d
The value by which we pre-roll is inconsequential, so long as we seek to the previous packet than the one we want. So 80ms will do.
MozReview-Commit-ID: 8iPOtjReZnb
--HG--
extra : rebase_source : 42908c6afc84cf783356fb7311ffe99b4ec76d96
mTaskQueue is only read on the main thread, but read and written on the demuxer's taskqueue. We need to ensure that accesses are synchronised.
MozReview-Commit-ID: Gbc15iYgZOe
--HG--
extra : rebase_source : 006ff3f73c9895fa2f29e56123e690cdf66fe2c5
Removed non-eager DDLogValue() functions, too confusing for not much value;
users should use macros first anyway.
Changed `EagerLogValue(..., const char (&aLiteral)[N])` to take `const char*`,
it's cleaner and simpler.
MozReview-Commit-ID: J7xcoPkp6Nf
--HG--
extra : rebase_source : 41040c98b89c3035c823a4a9775e727038c07590
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : ecce8ac75587470c15268ab729b068f049702a8a
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 9e455022ba9360fb549222e9ad1238a3ae9d88ad
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : 0d20f1b8648acaf2ed8e75b2631e905629c2abaf
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : 44ea3d0eb292e5c285d0aa4e10eefa41f20beed7
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 0334b71534cfaccaf1d8985d827fe4e5d5bf0e9f
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : b1dc3193d839ef3776195901339fae24f328207b
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
This is unnecessary work but simpler than adding a path to, or refactoring, AudioCallbackDriver::DataCallback.
MozReview-Commit-ID: GLNoBqxEuwz
--HG--
extra : rebase_source : b5ef6b2e1506e68d41b22ad557968d70214fbd9f
Owning the monitor is not sufficient for consistent state if state can be
accessed without the monitor.
The requirements for SetCurrentDriver() are tighted to require both the
monitor and correct thread, as CurrentDriver() can be called either with the
monitor or on the graph thread.
MozReview-Commit-ID: 90q7Pfa8jxn
--HG--
extra : rebase_source : 6cbcc334dc2bd355d2e9afdebda45a9624edda4b
This also permits setting mDriver to null after mDetectedNotRunning, which is
useful for fixing bug 1406830.
MozReview-Commit-ID: EEgAxqPQPRI
--HG--
extra : rebase_source : 56e1583a0090e683e92463536637d0f1460cb727
mLifecycleState is always > LIFECYCLE_RUNNING when mDetectedNotRunning
MozReview-Commit-ID: Ds6ybTv4miA
--HG--
extra : rebase_source : 71aea6693026dc919ea6d2096f55152ae12bc58e
Accessing the graphic device driver from the parent process, should the drivers crash have serious consequences (the whole browser dies).
MozReview-Commit-ID: EXXRBnDobQw
--HG--
extra : rebase_source : d5609f1e088c7bbe92d6e46e66e1fb5538d5caac
I don't know whether or not another zero initial AudioChunk member value
makes initialization more efficient, but zero for silence is more intuitive
for humans.
MozReview-Commit-ID: JEYv65btMul
--HG--
extra : rebase_source : 3089362ce4773da91c7139a3127e1491cbcf1dc5
This avoids any risk of undefined behavior when evaluating uninitialized
members, during copies for example, and makes it safe to test mBufferFormat
when null.
MozReview-Commit-ID: IMAyZ1CSHbk
--HG--
extra : rebase_source : b02431634732cf63d6fe9ede5eb1400a2baa6308
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
These listeners will be AddRefed/Released off the main thread when
OMT data delivery is enabled.
MozReview-Commit-ID: CSOBgNNf3OW
--HG--
extra : rebase_source : d9085c6447e51d3aa9cad79fa1e25d986fdee792
extra : intermediate-source : 21be6f0003e6d3ccf4448e6574ea5d3122665155
extra : source : 8ce13766af359b5e55524e47ea74bcfc0e0133f8
This moves the include into the file where it's used, and means I don't need
to import it into gecko-media crate yet.
MozReview-Commit-ID: JnEgtwnLxgO
--HG--
extra : rebase_source : 84f9b98e3c64dc1a337a12b714fd4c8bc45429a1
extra : source : 396e995935c6ada2a069c56cd1ede3c9ef418f31
This means MediaResource.cpp now only contains the stuff for the MediaResource
super class, and MediaResourceIndex.
MozReview-Commit-ID: 5xFxibn0aJ4
--HG--
extra : rebase_source : 4cb940008abb62c43759689cdc9e034d25b7e36f
This means we can simplify MediaResource.h to only include the abstract
interface, and MediaResourceIndex.
I also had to add a few includes here and there to fix the non-unified build.
MozReview-Commit-ID: 4R7LTXq25dm
--HG--
rename : dom/media/MediaResource.h => dom/media/BaseMediaResource.h
extra : rebase_source : edef4a65df4dcb92f8536052d170d78f95315753
It's only used in MediaCache.cpp, so it may as well be defined there.
MozReview-Commit-ID: HcA499xFOUg
--HG--
extra : rebase_source : f25c30d6e9be10549af80d5dfa963ef66abac576
It's only used in ChannelMediaResource.cpp, so it may as well be in there.
MozReview-Commit-ID: 5lyeFOoUsUN
--HG--
extra : rebase_source : 15aa06371c90e379e31383d2a8527d865944a4c3
It currently resides in MediaResource.h, but it's only used in a
ChannelMediaDecoder and ChannelMediaResource, so it doesn't need to be in the
abstract header.
MozReview-Commit-ID: GskE5mjMav1
--HG--
extra : rebase_source : b42321ddcb1966d4de7203f04852c14f6d271acd
DecoderDoctorLogger and its related classes offer a cheap way to gather log
messages from media stack objects, and then process these messages to extract
object lifetimes and messages related to separate HTMLMediaElement's.
MozReview-Commit-ID: AIf2nAMjoDy
--HG--
extra : rebase_source : cf10185538aded870b9005e88563751f3638ae65
Templated queue allowing safe and fast multi-threaded pushes.
Popping is not thread-safe (but concurrent pushes are still allowed.)
MozReview-Commit-ID: BHQ3nOlHkLX
--HG--
extra : rebase_source : 4a5dd6b603cbfe9bdd86df339469e870761d742a
Unsigned-number value-class with modified comparison operators that keep
ordering consistent across overflows.
I.e., numbers before the overflow (close to the maximum) will be considered
smaller than numbers after the overflow (close to 0).
(Note that such comparisons break down for numbers separated by more than half
the type range.)
MozReview-Commit-ID: 1hdK2JknlqZ
--HG--
extra : rebase_source : 7be3c1be6bc846e17dd5b396fcf097076b9096c1
Windows 10 Falls Creator Update build 16287 is known to have the fix to the problem that made bug 1403063 necessary.
MozReview-Commit-ID: 5m3ZWMes1yl
--HG--
extra : rebase_source : 5f6cd508de75f7e315f4334f76d64b389e4f2ce3
To avoid leaks caused by Dispatch() failures. See comment 0 for the detail.
MozReview-Commit-ID: 3lYxQNj1GPl
--HG--
extra : rebase_source : 8df990476a49544b475df39be789e3cb27853609
extra : intermediate-source : 012f42a1a9d46b0dafa31ca03da1c2bc4fc76d2e
extra : source : c6acb9362de9ab8d130104aaf102de2ecb27dc8f
Since we don't use state-mirroring to dispatch nextFrameStatus changes, we
can now revert the workaround of bug 1390443 P1. See bug 1390443 comment 0
for more details.
MozReview-Commit-ID: FRxXUnGC3x2
--HG--
extra : rebase_source : 67192634e001c635e2f15cc77545df79fed11b2d
extra : intermediate-source : 7c02f95ff9d1864fcc53216304b15c266634c753
extra : source : 6a46f27ac74f2c5b013ff8ace3ce8a77279a99b5
Use MediaEventSource instead of state-mirroring to notify nextFrameStatus
changes so we have more control over the order of events.
MozReview-Commit-ID: 3DGtMbghEQm
--HG--
extra : rebase_source : 774fc3da290c033769871a1bd7230177ff24d5bf
extra : intermediate-source : 6583b9281492be1a3bb0771b600cd80efd487af8
extra : source : 00570c319bfbd94970d4c637c7bf81b52d79ca02
To avoid leaks caused by Dispatch() failures. See comment 0 for the detail.
MozReview-Commit-ID: 3lYxQNj1GPl
--HG--
extra : rebase_source : 3ea4958ba21e691f83dbdf36fd820e597d6c5d68
extra : intermediate-source : 012f42a1a9d46b0dafa31ca03da1c2bc4fc76d2e
extra : source : c6acb9362de9ab8d130104aaf102de2ecb27dc8f
This allows for decoding VP9 profile 2 and 3.
At this stage, it is not possible to render the decoded frames.
MozReview-Commit-ID: DFXMvaM8Ynb
--HG--
extra : rebase_source : e17f24a00595461910f6d0cbd8ef4ba25453e8c5
The only actual code use in MediaSourceDemuxer can trivially be folded into
its caller GetNumberTracks in the same class.
MozReview-Commit-ID: E6zh98zmJwJ
--HG--
extra : rebase_source : 9358dc37523d6cd7c1a4d5ec62a790db6a092063
This allows for decoding VP9 profile 2 and 3.
At this stage, it is not possible to render the decoded frames.
MozReview-Commit-ID: DFXMvaM8Ynb
--HG--
extra : rebase_source : d9a639c2a65b1fd37d44336310af999e420155fe
So it is easier to run Update() loops off the main thread in the future.
MozReview-Commit-ID: LdxzQf6B3GK
--HG--
extra : rebase_source : 157984edf8ea08270fe61376e67183715b5bd4d4
extra : intermediate-source : f4045ce626977d392c799fae8f3d4f19efe3039f
extra : source : 778256b7055f4a470889eeae063660595d34337f
mStreamLength is always accessed within the lock. So it is safe to read/write
mStreamLength on all threads.
MozReview-Commit-ID: 9zJ2cwRrL5L
--HG--
extra : rebase_source : 10f282aa1c2fce2b9c0f431afb85e9d8ec7fab74
extra : intermediate-source : 38cac3d9015404aa3d1ddfd438ac57bd915fa0a7
extra : source : 60594740401732695f12f5f5232fa0f8e6681111
This verifies that screen content is captured correctly by drawing to a canvas
that is full screen and comparing to pixels in the captured stream.
Note that going fullscreen requires the tab (and window) to be in the foreground
and having focus.
MozReview-Commit-ID: 9SNXaCPm9da
--HG--
extra : rebase_source : bcd1fb1954acacbe4b7c51055f73ffc74a0e978f
AudioStream::DataCallback uses cubeb_get_backend_id to work around a bug in
libcubeb's winmm backend, but calling libcubeb APIs from within libcubeb
callbacks is not safe. Move the query to AudioStream::Init and check a simple
bool from within the callback instead.
So different test timeouts from the same test case will fall under the same bug.
MozReview-Commit-ID: LDstAhOpkYK
--HG--
extra : rebase_source : 9f2b52f237f18f3fecdd076295da4d43e5b30219
This patch does two things,
(1) check v.seekable after calling ms.endOfStream()
As test name suggests, we check seekable after calling endOfStream()
(2) check the time range of v.seekable
The seekable represents the ranges of the media resource [1], so it would be changed after calling ms.endOfStream().
Before calling the endOfStream(), seekable should be [0, ms.duration)
After calling the endOfStream(), seekable should be [0, ms.buffer.end(0))
[1] https://www.w3.org/TR/html51/semantics-embedded-content.html#dom-htmlmediaelement-seekable
MozReview-Commit-ID: 56AIZYVsHhW
--HG--
extra : rebase_source : a1f1df601dc8523cd5d4e58b41cada3c79d494c1
Use ErrorName() as it provides more useful information for the error detail.
MozReview-Commit-ID: BQUPQGcLd8L
--HG--
extra : rebase_source : 734825c88dfbe79de1e61498dcc24606c50314ee
Add telemetry to collect the following:
- Number of times a MediaRecorder is started during a session
- Duration of media recordings
- How often we're timing out init of audio and video track encoders
MozReview-Commit-ID: 9Pc2oKNCH1M
--HG--
extra : rebase_source : 16414a5ffa95413458d36295e5508df4c16e6fa9