This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
These two methods assert for OnGraphThreadOrNotRunning when their callers assert for OnGraphThread. Since the second assert is more limited we do not have to assert for a wider eventuality.
MozReview-Commit-ID: 2cgzO160l6F
--HG--
extra : rebase_source : 922a3d9775bb25022e456c19495b5e1666e7f8b7
That method is used on update of channelCount constraint. By raising a ControlMessage to MediaStreamGraph we avoid the lock the mutex on a non priority thread. Unfortunately we have to send the message in main thread first, thankfully this will change soon.
MozReview-Commit-ID: 8JRSmKGGVAN
--HG--
extra : rebase_source : 3d3a3f03ec601e5fbe0e8fda01608ee8cadf8d78
MediaStream::Destroy() is part of a controlled shutdown sequence.
If there are still tracks with content beyond Destroy() they will
only get caught by the dtor, which may be on CC shutdown and too late.
MozReview-Commit-ID: GV6XRiTCIRk
--HG--
extra : rebase_source : 88b5730c3566f8405c8f6da5e93e7cc446b9dd75
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : 03cefb8edf12b077607ae71aeb999fd0ac966674
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : b4310af51efa83c6670ba4e37433f7a23a575bba
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : 52d0b6a3b054238c79f1b224d6cbfcbaec743a67
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
With block size 128, rounding `128` to end of next block gives `256`, which is
not what we want when running MSG iterations. That could mean over-iterating and
buffering unnecessary amounts of silence.
MozReview-Commit-ID: vW14l2ygRy
--HG--
extra : rebase_source : 8aeedc8958e646f9730c9163447e3355a73fd42e
I hit this during local tests. It's a fine invariant but it doesn't hold in
forced shutdown.
MozReview-Commit-ID: HtoiGwf7IMI
--HG--
extra : rebase_source : 707de2fe08ccad99a06dab00969e2f140e63abad
With the added invariant that NotifyPull() needs a MediaStreamListener present
to not underrun, we need SetPullEnabled() and AddListener() to stay in sync by
using the same signaling mechanism.
MozReview-Commit-ID: 49KWdiTOG98
--HG--
extra : rebase_source : d0ad44d7ce431aa792c4908f96baf0c0920dbe90
There are legit cases when a SourceMediaStream gets pulled without a listener
present.
A clear example (though a corner case and easily overlooked) that I've hit is
when the last track is ended and the only stream listener is removed at the same
time. This leads to a pull on the next iteration where the track-end has not
yet been picked up. And thus, a false positive error saying that a live track
doesn't have listeners.
The real error here will now instead be caught by the new assert for when a
pulled stream underruns (which is now illegal).
MozReview-Commit-ID: 3e8FcCZfhYJ
--HG--
extra : rebase_source : ada823dbab07c8ca50429cd854b0c4b1df688fbb
Instead allocate it on the stack and provide it as out parameter.
MozReview-Commit-ID: 9fSJ68EfAga
--HG--
extra : rebase_source : 81430b45e4341d0f4208097f021c2a917e8e2645
This allows to re-use the SharedThreadPool across calls, preventing the need to create a new thread on each call.
MozReview-Commit-ID: CbP6OTYKhHL
--HG--
extra : rebase_source : 969f2c74f00614d6265fe0e25abfb36c9648d564
The operations is done in two ways:
1- Process all the MediaStreamListener at once, which returns a promise that will be resolved once the operation is completed.
2- As the Cubeb audio callback must be resolved immediately, the MSG will wait for all the promises to be resolved until it continues the operation of feeding the callback the necessary data.
This will allow to parallelize the stream's tracks' audio decoding.
MozReview-Commit-ID: EeoDvxnJyWV
--HG--
extra : rebase_source : 3d09af5aa3c80c4892a4d9af80842541d8fc33bb
There were two steps happening inside ExtractPendingInput:
1- Retrieve the data from the StreamTracks
2- Process any pending pending states change
We split it so that the retrieval from the StreamTrack can be promisified in an upcoming change
MozReview-Commit-ID: 53O4fXWMDGL
--HG--
extra : rebase_source : da082fa8db3a9029dc05d845cb9f58514f5ffcff
Despite the name of the function, the original SourceMediaStream::Finish() (consequently renamed FinishPending) didn't actually finished the stream, but instead set a bool that would indicate to completely finish the stream once ExtractPendingInput ran. But here it could never run again.
So actually do what the original fix intended to do (bug 1410829)
MozReview-Commit-ID: 1hHiOLiovG
--HG--
extra : rebase_source : 7b108a96b54c92812ba583b0dc78ceddbfe15636
It is good practice for the MSG to now know the implementation details of the MediaStream.
Additionally, this will allow to make a thread-safe version later.,
MozReview-Commit-ID: CTacCLSeKRP
--HG--
extra : rebase_source : 4feb4beb12f4cd2a6fb67fd6a18f003ea8b18869
We have different concept of "finish" between the base class and its hierarchy.
Attempt to clear the sitatuation by renaming the members and related methods.
MozReview-Commit-ID: vFsXhMK5GY
--HG--
extra : rebase_source : 65eda9257e447584161da51af7c240e31027c501
The MSG shouldn't have to know about the inner details of the SourceMediaStream
MozReview-Commit-ID: 2S81SPzy09E
--HG--
extra : rebase_source : dff8384b19442e7686cef42420372e39f10094b6
Now that the graph rate match the one out of NetEQ, we can remove an unecessary conversion.
Additionally, move a member from the base case to the only one where it's used.
MozReview-Commit-ID: II5mdcl0vhK
--HG--
extra : rebase_source : 1d9edfc2803c3fadde7505b4d84293640e4311e0
The method doesn't use any MSG member, only dispatching a task.
MozReview-Commit-ID: 7uZbTvq9OQt
--HG--
extra : rebase_source : e12c5ffcb6479ab2bc06973121c291e759db23a4
mForceShutdownTicket and mShutdownTimer are only ever accessed on the main thread. We don't need the use of the monitor to reset them.
MozReview-Commit-ID: 1DL8bLmzEH5
--HG--
extra : rebase_source : 84d56c7f4428143426cd22e88ef2912330efba4e
We only access mLifecycleState via a helper which strongly enforced how the member can be accessed.
Two non-safe accesses are corrected.
MozReview-Commit-ID: 6LYk7t4rSyB
--HG--
extra : rebase_source : 9727771e1b04ba1b39f5cf9a6cf94093b7e92b27
They are accessed across multiple threads without the use of monitors.
While it could be argued that some use of the monitor in functions accessing those members would set in place memory barriers, making them atomics remove all doubts as to the thread safetyness of their use.
MozReview-Commit-ID: tyTqeGgDNM
--HG--
extra : rebase_source : 420c38abcfeaa5fca2449034d8e1e3d82949d49d
When shutting down we shut modules down in the order of
[media, gfx, cycleCollector].
At the same time we rely on destructors to clean up resources for MediaStreams
and MediaStreamTracks, but these objects may be held until cycleCollector
shutdown. Gfx resources are not allowed to be released after gfx shutdown, which
is where we this approach hits a wall.
This patch will signal them through the three available listener types to clean
up during media shutdown.
MozReview-Commit-ID: FwsG3ukV29P
--HG--
extra : rebase_source : 554ec29a43b7551b3b5570577b0559285e36d4fd
The first AsyncCubebTask dispatch from AudioCallbackDriver::Start() may either
be from MediaStreamGraphImpl::RunInStableState() on the main thread or
ThreadedDriver::RunThread() on a threaded driver thread.
These could potentially occur concurrently when there are multiple
MediaStreamGraphs.
This change removes the race around setting sThreadPool.
SharedThreadPool::Get() would have returned the same pointer, and so
that race was probably mostly benign apart from the potential to add an
extra reference and so hang on shutdown in SharedThreadPool::SpinUntilEmpty().
Storing the reference to the SharedThreadPool on the object using it is the
typical way to use SharedThreadPool. It lets the thread pool be released when
not in use, and lets SharedThreadPool deal with multi-thread access and
shutdown.
MozReview-Commit-ID: 8WutVsAMfJo
--HG--
extra : rebase_source : a3d0ce75d65889fff47389ccd80640c3f1150244
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
There were some cases where these tracks were detected as ended when they were
in fact not. That result in problems in the MediaRecorder.
MozReview-Commit-ID: 4CNUYRvzOgK
--HG--
extra : rebase_source : b94c29bc73e76575489a4684facc0b01bb7aeb22
extra : source : bedb7abcc84263c6a6369c4d05e8bf3287281090
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
This causes a number of issues, like bug 1329082, where we don't swap the
message queues of the MSG where we should, and blows up an assert in debug.
MozReview-Commit-ID: 2I3IjfK8L8r
This mostly simplifies the code, but there are two changes to the logic as well.
1) The decision to install the listener or not used to be based on if the track
existed in mUpdateTracks, while feeding the sink would look at the
StreamTracks as well. This now looks at StreamTracks since an ended track is
kept there but removed from mUpdateTracks. That means that we also
NotifyEnded() if the track was in the StreamTracks but not in mUpdateTracks.
2) I removed the code that feeds a video stream sink with the last chunk in
case the graph's current time has passed the end of the track. Tests should
be written so that we have guarantees that there will be video data when a
video stream sink gets added. If this fails we should fix the root cause of
such a timing issue instead of wallpapering it with an old frame. I think
this could be masking other issues. We'll see how this acts out on try.
MozReview-Commit-ID: KKr9JhVpxZt
--HG--
extra : rebase_source : f775fcfbe9647e29ee107ecc7b1f39c2d91f3b0d
extra : histedit_source : 4fa675ce93dc67d7db972a07bb3236f34707e7d3
Emilio Cobos Álvarez
Alex Chronopoulos
Andreas Pehrson
Paul Adenot
Narcis Beleuzu
Andreea Pavel
Cosmin Sabou
Sebastian Hengst
Tristan Bourvon
Ben Kelly
Chris Peterson
Karl Tomlinson
Jean-Yves Avenard
Kris Maglione
Andreas Pehrson
Wes Kocher
Matthew Gregan
Carsten "Tomcat" Book
Bevis Tseng
Kartikaya Gupta
Andrea Marchesini
Bill McCloskey
Jan-Ivar Bruaroey
Tom Tromey
Randell Jesup