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
Takes either a MozPromise or an AllPromiseType and will execute the resolve/reject functions synchronously once the promise has resolved/rejected.
MozReview-Commit-ID: EyfMTPtA1Lu
--HG--
extra : rebase_source : 780ab41307158d7887cd76782e43693079f78c91
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
Note SharedInfo contains an array to store the original and cloned resources.
This allows us to iterate over resources on the main thread without taking the
cache monitor.
MozReview-Commit-ID: K3gcPYbf72Z
--HG--
extra : rebase_source : eaa070a889797c29d2599b4c3d2507f440d476e7
extra : source : 5dc420815d7a26771c176cdc7b6a87a1c2278da8
This adds a scaling factor of 0.5 even when normalization is
disabled, which is required for correct results.
MozReview-Commit-ID: J0VbMcaacGc
--HG--
extra : rebase_source : 1a8e2dd21a6a48a02fbafda994e42b59c5761ea4
To be consistent with other functions.
MozReview-Commit-ID: 1adZkXx2VkB
--HG--
extra : rebase_source : b7c420c717ffc95feb73749305fd25e3bba12ae1
extra : intermediate-source : a7a9f6ae0a0291c76f2eee0e89f57684df98a061
extra : source : 9055561c3203e06c0e2d6d0daaa76f3e85dc1b2c
GetOwner()->DownloadProgressed() will update readyState of the media element
which will need to read mCanPlayThrough.
MozReview-Commit-ID: EDHlLJjKDoL
--HG--
extra : rebase_source : df4ffabc02f9e6b4b20e5fa6c9be6988570a9974
extra : intermediate-source : 371a6509c04bf89edb07b3437a41a9b36dba25ff
extra : source : 227ffb87de637994baefab6b178afeae4673a2ef
Note we cache the result of GetStatistics().CanPlayThrough() which is needed
by CanPlayThroughImpl().
MozReview-Commit-ID: QYNqk1pUN5
--HG--
extra : rebase_source : e4ce549f1069fd3106da4f68dcb429afa291aa5d
extra : intermediate-source : 9d7c532bdad7733bc3f9e725feecd83bea1ab156
extra : source : b552dad39a644026eb0d62e7e975c4120e550447
This will be used by ChannelMediaDecoder to run some code off the main thread.
MozReview-Commit-ID: 7Ecej11GBvy
--HG--
extra : rebase_source : aeafd934cb76d426d3c4f49ebd0736b013cbe588
extra : intermediate-source : 5cb1e7b389daf48c77c2e0bf632cefaeff5a2b40
extra : source : 813e6593f8e9772895df7acb353dbf0137008bb0
When looping videos in a background tab, SeekingState::Enter() will switch off
blank decoder and then DecodingState::Enter() will switch it on again. It is a
waste of CPU cycles when the tab never goes to the foreground. The overhread is
even more significant when looping short files.
We should resume video decoding only when necessary that is we check in
DecodingState::Enter() to see if mVideoDecodeSuspended matches mVideoDecodeMode.
MozReview-Commit-ID: 54vq7mEjWQf
--HG--
extra : rebase_source : ce04310d06df2effd65d8c301e07c7fef01bdbd1
extra : intermediate-source : 83dff897174fb440e5da24843186ff9fd39d15c9
extra : source : d0834777c96255e15dc44d1865bd354ab67ec8fe
Usually mDecoderPosition and mPlaybackPosition are in the same cached range so
GetCachedDataEnd(mDecoderPosition) and GetCachedDataEnd(mPlaybackPosition) will
give the same result.
It also makes more sense to pass the playback position instead of decoder
position since 'canplaythrough' is about playback instead of decoding.
MozReview-Commit-ID: Kk1uUeSFTCI
--HG--
extra : rebase_source : 1f40adce4b93dbcf55cb3de9f5c16fdd6d0b6bee
extra : source : 9c77dddb2faca84bd8cf09fc2007e18986e62f64
The reason explained in patch Part1 of Bug 1214018 and I just copy the reason below.
GetRawMachineId was returning its generated data through a 'string16', which on
Windows was conveniently equivalent to a std::wstring.
However on Mac, wstring uses 32-bit characters, so in order to comply with the
string16 interface, a lot of non-trivial code would have to be imported and
vetted.
Also, in the end GMPLoader::Load passes this string16 to SHA256_Update() as a
sequence of bytes, the actual type of the data is lost!
So to simplify this work, GetRawMachineId will now return its data through a
vector of bytes, and the platform-dependent implementations may use whatever
data type they want internally.
The Windows GetRawMachineId actually returns the same data in this vector, so
it stays compatible with the previous code.
MozReview-Commit-ID: 7xYgjndXWDX
--HG--
extra : rebase_source : 6a46bd7f06d6e4bc10bb98b600e7e5bc14c136ce
Chromium uses rlz_lib::GetMachineId as a factor when calculating storage id.
MozReview-Commit-ID: AJbcnRXzi3m
--HG--
extra : rebase_source : 4e6a0eebaeec01fc7a78caeb8406d1e2ed09f1d4
Sync with the upstream(Chromium src/rlz/) and try to revert the functionality of Bug 1332530.
rlz is linked into xul.
MozReview-Commit-ID: HsjnBRPnifh
--HG--
extra : rebase_source : 2867fe353d0c8c67535d29943f3536ef59d1d75e
We need to feed deinterleaved data, not interleaved data.
MozReview-Commit-ID: 99z8HA7tJgT
--HG--
extra : rebase_source : eb61b602630008683c6afdd2aad1dca0d663db86
extra : intermediate-source : 2d718ca90e07d9dfc71e86434cb04c5580405f9f
extra : source : 3ba7fe1cddec0a3dcaaf526a85b7f34072c3e199
This brings in a lot of noise and makes the test fail.
MozReview-Commit-ID: 70EGM1q1J24
--HG--
extra : rebase_source : cab81fdfd53c537c04f1d2360a9340a3740b66a0
extra : source : c02fd9acc634860ef540a0cddb1591f294fc1f61
This also is long, but simple.
First, we switch to floats everywhere. This allows to work with any rate, is
more flexible with channel layout, and is a stable API (see audio_processing.h
in webrtc.org).
Then, 10ms worth of audio (already at the graph rate) are poped from the
lock-free queue (fed on the other end by the MSG mixer), and does the following:
- Down mixing to stereo (if needed)
- De-interleaving into planar buffer
- Prepare input and output config
- Actually make the API call
- Free the data
Now, first, we should use a ring buffer, and not have to free any data. Then we
also should not use a lock-free queue, and synchronously process the
reverse-stream, but this is enough code already.
Then, the actual mic data processing:
- Pop a packet from the packetizer (that gives us 10ms worth of audio, note that
we switch from int16_t to float, i.e. we don't do this conversion anymore).
- We convert to planar buffers, deinterleaving
- Prepare input and output config
- Allocate a SharedBuffer of the right size
- Process the data with the processing algorithm selected in UpdateSingleSource
- Append to the a MediaSegment, and append to the right MediaStreamTrack for the
correct SourceMediaStream (the data is already planar and all well).
MozReview-Commit-ID: 2IjgHP0GAmw
--HG--
extra : rebase_source : 1e08c4a781db8778e0532f9ef1a8e369513a2c66
extra : source : 0107b3feb84bbe0e643f505ec58e303dfd94e1a7
This part is about setting on/off audio processing feature. It's long, but
it's mostly mechanichal changes, from the old API to the new one.
This also covers reseting the processing in case of device changes (with
macros).
MozReview-Commit-ID: EI2TxHRicEr
--HG--
extra : rebase_source : 5c389e00019633d371d74cdd2d881dab4d353848
extra : source : 2c7a56648de9125ae1893d54ec011b6cbb181d86
This needs the next patches to build fine, but is split out for the review.
A side effect of this patch is to break non-duplex, making the whole
init/cleanup phase much simpler.
MozReview-Commit-ID: Caqc8v7CWwZ
--HG--
extra : rebase_source : 604551cc937ee60064a263ebb5fb1550fa9a9e9f
extra : source : a781b123b252b464f805674144cc01d9dd69c391
This is "just" for testing, but is cleaner, and skips some resampling, and is in
line with the other patches, to converge with always using MSG rate when we can.
MozReview-Commit-ID: CBQHEDQWJE3
--HG--
extra : rebase_source : 9cc113efbaa982c20d62c2863ce231dda4735257
extra : source : bf8977e0f440c0280da32a7052214834dc6701ca
