webrtc.org only supports one-byte rtp header extensions which means
we can only support 16 character mids for now.
MozReview-Commit-ID: C7aTeB5Bi2M
--HG--
extra : rebase_source : e25518d02fb056f82d298f000e37cfe059099a38
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : rebase_source : 2f45ef1473c2bbf2882fe867e8b535998b8dc9ef
This adds new tests that are a subset of the existing tests for configuration.
Another option would be to use parameterized tests to get coverage of all existing
tests during reconfiguration, but I don't think the additional complexity is
justified at this point.
MozReview-Commit-ID: F28KRYaVe1B
--HG--
extra : rebase_source : fdcb1316387504240424f1041d43df5d98331380
This is necessary for changes to encoding constraints and simulcast encodings to
be picked up.
MozReview-Commit-ID: JpVN0ST70Cn
--HG--
extra : rebase_source : ea61544b98e7e231527cf6f13d78862d3567b4b7
We had to force-include Char16.h to simulate char16_t on older MSVC versions.
But it is no longer the case. We should not rebuild the world whenever we
touch this file.
MozReview-Commit-ID: 1XY7tQD8LoK
--HG--
extra : rebase_source : a08ccfc9b6a4abf90f6f8b97a42079865724c9ec
>+#if !defined(_MSC_VER) && (_MSC_VER < 1600)
is wrong. It should have been:
>+#if !(defined(_MSC_VER) && (_MSC_VER < 1600))
But I reverted this local change completely because we do not support such
older MSVC versions anyway.
MozReview-Commit-ID: 3VhtViP7WpX
--HG--
extra : rebase_source : f18f57d8505e5847452263847d561b5cdef255b7
Also remove unused code.
mTrackId / mTrackIdexternal were protected/private members and only ever written.
MozReview-Commit-ID: C3wMhxSCA2H
--HG--
extra : rebase_source : 18845e480e8e2d741ef1172b212373888a9c1fe8
It can never be nullptr, strongly assert that this is the case and remove unecessary tests.
MozReview-Commit-ID: 7fi6jNnFUH8
--HG--
extra : rebase_source : 632ad1738c2984dd803c25dc44aa81c896292b64
Otherwise we will use 48kHz as default, the MSG will resample as needed.
It would be possible to allow all frequencies in the AudioConduit as the webrtc backend supports them all, however it would require more changes and likely heap allocation that we're trying to limit in this part of the code.
MozReview-Commit-ID: B3x5t1FSaQ8
--HG--
extra : rebase_source : 77f83a876ed9b5ded45419245655709aee2573df
Also remove the unmatched candidates in the candidate pair table since
they are now included in the "all raw candidates" table.
MozReview-Commit-ID: 4ZvhWfmjGJh
--HG--
extra : rebase_source : bf999db83cd49dd454434d2b157023da41b0dbcd
Adding trickle field that will allow us to flag trickled candidates
on about:webrtc.
Also added label field to NrIceCandidate to facilitate showing the
raw candidate info on about:webrtc.
MozReview-Commit-ID: HuP3IxYOOBJ
--HG--
extra : rebase_source : 975cb5b29b2aef233f856bfbdc8c325535d24272
This is a workaround for the fact that our code is wrong.
FakeAudioDeviceModule :::TimeUntilNextProcess() returns 0, so we're busy
looping.
I'm switching that to 100, which is arbitrary, but makes the problem go away. I
want to fix that soon, because this is a terrible workaround.
FakeAudioDeviceModule is _not_ made to be used in production.
MozReview-Commit-ID: FoGs6GFsRRN
--HG--
extra : rebase_source : d62f7c2d5b98c4814c06be13aca49bd478d5b381
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
There's no need for a custom class to perform this task.
MozReview-Commit-ID: JxpDQVM97fl
--HG--
extra : rebase_source : 8387efa0ed3add9e4a42daed98e97372d9cabee5
We keep the synchronous version that will be used in bug 1424653
MozReview-Commit-ID: JTGaRYm20ca
--HG--
extra : rebase_source : aa694b7ac4f03322edbdefd64cefd198c0909cec
It allows to more easily distinguish between methods from upstream webrtc.org and our code.
MozReview-Commit-ID: ILQhEAYbSmc
--HG--
extra : rebase_source : 934505afddcca9253b00c4094776c95a087058fb
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
Also, pass arguments are const reference.
We also rename class members as per coding style.
MozReview-Commit-ID: 9IkV8wCMpz7
--HG--
extra : rebase_source : 6dc8285342742bf19dd2d03f66dd0668fc32bbcc
It removes the need to explicitly shutdown the taskqueue and wait on the taskqueue to have run all dispatched task.
We do want to enforce that no listeners are being called once the VideoFrameConverter's owner has been destroyed as it could potentially lead to a UAF.
For now, access is okay as all operations are performed on the MSG's thread.
However, this will change in follow up patches.
The SourceMediaStream keeps a raw pointer to the MSG, and check if it's value isn't null to determine if the MSG has been shutdown or not, however SourceMediaStream::mGraph isn't thread safe as its access isn't protected by a mutex/monitor.
MozReview-Commit-ID: 1QsJAzPuE6L
--HG--
extra : rebase_source : 35f34450e62ff1f445ad6ccd06c6f6cbd3c6ed54
It's bound to be done automatically, makes it easier to modify later.
MozReview-Commit-ID: IQ5TBtS8Z3v
--HG--
extra : rebase_source : 0b1a326ada5761cfa50c33acbff9b61cf4e59c8c
The MSG provides the reverse stream, and feed it directly to the APM.
MozReview-Commit-ID: A6DO407CJkp
--HG--
extra : rebase_source : df4ad965c171eab5a72a8d09e0305b1e79325a03
extra : source : e92ff1339db1ca5affa56ccdbec1c8b3836bcd95
This forces us to do a copy. It's not the end of the world but could be avoided.
The number of channels received is now explicit (via
`AudioFrame::num_channels_`), instead of being guessed based on the number of
samples (considering we're always dealing with 10ms of audio, and we know the
rate).
It's still coupled a bit with audio devices, but we cheat, and use a "fake audio
device", which isn't going to touch actual OS APIs.
MozReview-Commit-ID: 1Tfajkv1HQR
--HG--
extra : rebase_source : c0c8c240621b076bb3b056689f45289212498903
extra : source : 9e92591ba6dcb18364da98756c645c91bfe81517
We used to fix the rate, arbitrarily, to 32kHz. Because the graph is almost
never running at 32kHz (more like 44.1kHz or 48kHz), and the codec would often
not be at 32kHz, this meant multiple resampling:
- Once here, in MediaPipeline, to bring to 32kHz
- Once when getting inserted in the MSG (so that the audio was brought back to
MSG rate)
- Maybe once in cubeb (depending on the platform)
This always removes the second resampling: the track is now at the correct rate,
as far as the MSG is concerned.
Additionally, if the MSG is running at 48kHz, more resampling are saved, because
it's one of the native webrtc.org rates.
MozReview-Commit-ID: DBWcwuWxUpu
--HG--
extra : rebase_source : 2b961a8bd91d952ccbe9df5a6ab7649321f282a6
extra : source : a3d9aa2649b95329d0cf686d79aa5179e9f3506d
Nothing significant in this release, just to be in sync with upstream
MozReview-Commit-ID: GOMzG6TOHYg
--HG--
extra : rebase_source : 73c7a83e358d0b8c7686f0b79d805947c928600e
The MSG provides the reverse stream, and feed it directly to the APM.
MozReview-Commit-ID: A6DO407CJkp
--HG--
extra : rebase_source : 65515c02928ed56d57ddd2facd586125df7f09ec
extra : histedit_source : fc61533566deca6023cb749acda96b5772661ebc
This forces us to do a copy. It's not the end of the world but could be avoided.
The number of channels received is now explicit (via
`AudioFrame::num_channels_`), instead of being guessed based on the number of
samples (considering we're always dealing with 10ms of audio, and we know the
rate).
It's still coupled a bit with audio devices, but we cheat, and use a "fake audio
device", which isn't going to touch actual OS APIs.
MozReview-Commit-ID: 1Tfajkv1HQR
--HG--
extra : rebase_source : f9ed6f1beeb3745dc17c4e6264808d1918e8906c
extra : histedit_source : 4338aea961b861462caa79afab66ebaea06e40b2
We used to fix the rate, arbitrarily, to 32kHz. Because the graph is almost
never running at 32kHz (more like 44.1kHz or 48kHz), and the codec would often
not be at 32kHz, this meant multiple resampling:
- Once here, in MediaPipeline, to bring to 32kHz
- Once when getting inserted in the MSG (so that the audio was brought back to
MSG rate)
- Maybe once in cubeb (depending on the platform)
This always removes the second resampling: the track is now at the correct rate,
as far as the MSG is concerned.
Additionally, if the MSG is running at 48kHz, more resampling are saved, because
it's one of the native webrtc.org rates.
MozReview-Commit-ID: DBWcwuWxUpu
--HG--
extra : rebase_source : 588d188f63237f1ce2cb0f2b290d54797d2d22e8
extra : histedit_source : 51733a22f6019140f7a309038a2ff524fbb564a4
* +x on the script
* add the #!/bin/sh
* check the number of args
* readme has been renamed
* todo.txt no longer exits
MozReview-Commit-ID: 67JIO610CNg
--HG--
extra : rebase_source : ee717814cb1f2cd64369caa0c7ee89dedad61c66
Specifically: without this fix, icecc + clang users will hit this clang bug when compiling stdatomics.h:
https://bugs.llvm.org/show_bug.cgi?id=26828
MozReview-Commit-ID: BJUN82HyXpF
--HG--
extra : rebase_source : 3f06d3401198de45240aa9f0c7c865e048f90b89
