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
