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
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 : dde23b590c3eebe9fb56dba2d81738059efde654
Add a new |offerer| field to RTCStatsReport.
Based on offerer, label the local sdp as offer or answer.
Based on offerer, label the remote sdp as offer or answer.
MozReview-Commit-ID: 4jdWP8tpr9w
--HG--
extra : rebase_source : 5724645ef8e39c2af0c5fccf7d7872ee2cb437b5
C5038 is a new warning in VS2017, similar to gcc and clang's -Wreorder, which is enabled by -Wall. We should enable C5038 so Windows developers can see these warnings locally instead of when gcc and clang fail with warnings-as-errors on Try.
https://blogs.msdn.microsoft.com/vcblog/2017/07/21/diagnostic-improvements-in-vs2017-15-3-0/
We need to suppress C5038 warnings from Windows Runtime Library header files (wrl.h) included in ANGLE and widget/windows:
z:\build\build\src\vs2017_15.4.2\SDK\Include\10.0.15063.0\winrt\wrl\wrappers\corewrappers.h(515): error C5038: data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::sync_' will be initialized after data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::status_'
...
And suppress C5038 warnings in upstream webrtc code:
media/webrtc/trunk/webrtc/modules/video_capture/windows/BaseFilter.cpp(176): error C5038: data member 'mozilla::media::BaseFilter::mClsId' will be initialized after data member 'mozilla::media::BaseFilter::mState'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(169): error C5038: data member 'mozilla::media::BasePin::mFilter' will be initialized after data member 'mozilla::media::BasePin::mLock'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(170): error C5038: data member 'mozilla::media::BasePin::mLock' will be initialized after data member 'mozilla::media::BasePin::mName'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(172): error C5038: data member 'mozilla::media::BasePin::mDirection' will be initialized after data member 'mozilla::media::BasePin::mQualitySink'
MozReview-Commit-ID: BMDVkvQXNoq
--HG--
extra : rebase_source : 0d5ede9530d0d0750b8fffdc1cdfdc646ec8f22a
state_callback() and data_callback() can be called from multiple
threads. To protect the send/receive pair of calls, a Mutex is added
to Connection to prevent one thread from starving when two threads try
to wait on the socket in recvmsg.
MozReview-Commit-ID: LUXcqnw2Hm1
--HG--
extra : rebase_source : e98f50a109510e35bab6516febc9e76539c3228f
This changes code in PlatformUIThread::Run to match what was present in
ThreadWindowsUI::Run prior to the branch 49 update. With this update in place
it is possible to limit framerate on Windows again. The limit does not work
as well as on other platforms, the actual framerate seems to be 1.5x to 2x
the request value on the systems I have tested. That was also the case prior
to the branch 49 update.
MozReview-Commit-ID: W5xnWfkaET
--HG--
extra : rebase_source : dc4422864306063e83e6e1f4a7d51a0d97cbf1c6
Update our in-tree copy of libogg to the latest upstream release.
This fixes an issue handling corrupt streams when packets are
continued between framing pages, along with some minor portability
fixes.
MozReview-Commit-ID: 3Vixrru4gLV
--HG--
extra : rebase_source : be30a403c32ec777c57ca95fcc642abf875188ae
SSE2 isn't enabled by default on BSD x86 systems which ends up disabling
SIMD-optimized routines in libyuv. As Clang can build the code fine without
-msse limit the requirement to GCC.
https://github.com/llvm-mirror/clang/blob/6fc97e7c1cf4/lib/Driver/ToolChains/Arch/X86.cpp#L98
MozReview-Commit-ID: BaVAbEpkoHj
--HG--
extra : rebase_source : d32d55c09f34ad2d8d9e0d275167b576c9070e65
It was incorrectly disabled during the last resync.
MozReview-Commit-ID: IP0T4Aq5Q2q
--HG--
extra : rebase_source : 77b3c792ddabfc5536b8c680010d0438a22699be
The system ffmpeg will be used instead or libvpx if not found.
MozReview-Commit-ID: GX5WWPOhPq9
--HG--
extra : rebase_source : 3eec2ee1bc3b66d88653b913d6d1b3ad1a5d5acd
Two variables, contains_mac_based_ipv6 and contains_teredo_ipv6, were
added that are set but never used. This will cause compiler warnings
issues in the future.
MozReview-Commit-ID: C5ZReH94RpM
--HG--
extra : rebase_source : 50e06da3c093a118151d840b7d25a979afce6321
This revision of libaom has some conflicts with our vendor script
and build system. A number of new .asm files have the same basename
as .c files, which our build system cannot handle.
To work around this, I ran `./mach vendor aom` with the check for
duplicate filenames disabled, then manually renamed the conflicting
files in the filesystem and sources.mozbuild.
Also add av1_convolve_scale_sse4.c to sources.mozbuild manually.
This is needed by the build but for some reason isn't picked up
by generate_sources_mozbuild.sh.
MozReview-Commit-ID: 2iBo4kSBz1G
--HG--
rename : third_party/aom/aom_dsp/arm/idct16x16_1_add_neon.asm => third_party/aom/aom_dsp/arm/idct16x16_1_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/idct16x16_add_neon.asm => third_party/aom/aom_dsp/arm/idct16x16_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/idct32x32_1_add_neon.asm => third_party/aom/aom_dsp/arm/idct32x32_1_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/idct32x32_add_neon.asm => third_party/aom/aom_dsp/arm/idct32x32_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/idct4x4_1_add_neon.asm => third_party/aom/aom_dsp/arm/idct4x4_1_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/idct4x4_add_neon.asm => third_party/aom/aom_dsp/arm/idct4x4_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/idct8x8_1_add_neon.asm => third_party/aom/aom_dsp/arm/idct8x8_1_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/idct8x8_add_neon.asm => third_party/aom/aom_dsp/arm/idct8x8_add_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/loopfilter_16_neon.asm => third_party/aom/aom_dsp/arm/loopfilter_16_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/loopfilter_4_neon.asm => third_party/aom/aom_dsp/arm/loopfilter_4_neon_asm.asm
rename : third_party/aom/aom_dsp/arm/loopfilter_8_neon.asm => third_party/aom/aom_dsp/arm/loopfilter_8_neon_asm.asm
rename : third_party/aom/aom_dsp/x86/highbd_intrapred_sse2.asm => third_party/aom/aom_dsp/x86/highbd_intrapred_sse2_asm.asm
rename : third_party/aom/aom_dsp/x86/intrapred_sse2.asm => third_party/aom/aom_dsp/x86/intrapred_sse2_asm.asm
rename : third_party/aom/aom_dsp/x86/intrapred_ssse3.asm => third_party/aom/aom_dsp/x86/intrapred_ssse3_asm.asm
extra : rebase_source : 7bf598ac1a925e16e42301839376a963836ae182
Update to upstream commit id e87fb2378f01103d5d6e477a4ef6892dc714e614
from a couple of weeks ago to pick up changes.
MozReview-Commit-ID: H7H69A7qFXD
--HG--
extra : rebase_source : dee676da15b65e4eea612d20529c4fb312bbddfb
