Turns out that if mb_type is missing in the JSON, GYP is run the
traditional way instead of having the MB configuration decide.
This turns on MB for those builders.
See https://codereview.chromium.org/2194703002 for how Chromium
switched from GYP->GN.
The JSON environment for GYP and GN is only used during runhooks
step since there are scripts that key on some of these environment variables.
The actual build that is compiled is defined by the MB config, which
is now updated to have component=static_library everywhere for iOS.
With this CL, all configs gets a full GYP+GN environment.
When flipping bots over to GN, the following line will need to be added
in addition to changing mb_type:
"additional_compile_targets": [ "all" ],
Goma was also enabled for all builders to reduce compile time.
BUG=589510
NOTRY=True
Review-Url: https://codereview.webrtc.org/2239643002
Cr-Commit-Position: refs/heads/master@{#13775}
Reason for revert:
Failed on Win 10 Chrome FYI.
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Win10%20Tester/builds/3847/steps/content_browsertests/logs/stdio
#
# Fatal error in e:\b\c\b\win_builder\src\third_party\webrtc\base\task_queue_win.cc, line 138
# last system error: 87
# Check failed: ((DWORD)0xFFFFFFFF) != result (4294967295 vs. 4294967295)
#
WebRtcBrowserTest
#
Original issue's description:
> - Add task queue to Call with the intent of replacing the use of one of the process threads.
>
> - Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
>
> - BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
>
> - VideoEncoderConfig and VideoSendStream::Config support move semantics.
>
> - The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
>
> BUG=webrtc:5687
>
> Committed: https://crrev.com/cc168360f41322332860cb075edeb1cde21aa473
> Cr-Commit-Position: refs/heads/master@{#13767}
TBR=tommi@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org,sprang@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2248713003
Cr-Commit-Position: refs/heads/master@{#13774}
-Removed the old probe cluster logic and use the new ProbeBitrateEstimator
instead.
-Removed all logic related to ssrcs from DelayBasedBwe as they have no function
on the sender side.
BUG=webrtc:5859
R=stefan@webrtc.org, terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2234363002 .
Cr-Commit-Position: refs/heads/master@{#13771}
New files, classes moved from statscollector_unittest.cc:
+webrtc/api/test/mock_peerconnection.h
for MockPeerConnectionFactory and MockPeerConnection
+webrtc/api/test/mock_webrtcsession.h
for MockWebRtcSession
+webrtc/media/base/test/mock_mediachannel.h
for MockVideoMediaChannel and MockVoiceMediaChannel
The webrtc/media/base/test folder is new.
BUG=chromium:627816
Review-Url: https://codereview.webrtc.org/2238933002
Cr-Commit-Position: refs/heads/master@{#13769}
This is in preparation for adding a gn target for audio_device_tests.
BUG=webrtc:6170,webrtc:163
NOTRY=True
Review-Url: https://codereview.webrtc.org/2222563002
Cr-Commit-Position: refs/heads/master@{#13768}
- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
- VideoEncoderConfig and VideoSendStream::Config support move semantics.
- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2060403002
Cr-Commit-Position: refs/heads/master@{#13767}
A recent DrMemory failure has been detected after change 2099123002. After some
investigation, an uninitialized read has been detected in
NtUserGetThreadDesktop
webrtc::Desktop::GetThreadDesktop
webrtc::ScopedThreadDesktop::ScopedThreadDesktop
webrtc::ScreenCapturerWinGdi::ScreenCapturerWinGdi
webrtc::ScreenCapturer::Create
webrtc::ScreenCapturerTest_UseDirectxCapturer_Test::TestBody
So there are two issues,
1. The Directx capturer won't be triggered as the system does not support it. So
these tests should be disabled in this scenario.
2. An uninitialized read in NtUserGetThreadDesktop -> ScopedThreadDesktop
stacks, which should be suppressed. By default, these suppressions should be
placed in chromium/external with other suppressions.
So this change is a quick fix to the failure, do not use ScreenCapturerWinGdi in
ScreenCaputrerWinDirectx tests.
BUG=
Review-Url: https://codereview.webrtc.org/2247943002
Cr-Commit-Position: refs/heads/master@{#13766}
H.264 frames may have AUD before SPS. This change detects AUD and try to extract SPS and PPS behind AUD.
BUG=webrtc:6173
Review-Url: https://codereview.webrtc.org/2209143002
Cr-Commit-Position: refs/heads/master@{#13765}
When playing out, for example, you'd see 3 lines for every call to
PlayoutDelay, which happens quite often (every sample?).
The ones around the Playout/Recording Warning/Error are only once a
second, but they don't seem to add anything. Same with
Process/TimeUntilNextProcess, which just log that the method is called.
BUG=
Review-Url: https://codereview.webrtc.org/2202243004
Cr-Commit-Position: refs/heads/master@{#13763}
when building with default warnings.
This is in preparation for making a gn target for audio_device_tests.
BUG=webrtc:6170, webrtc:163
NOTRY=True
Review-Url: https://codereview.webrtc.org/2219653004
Cr-Commit-Position: refs/heads/master@{#13759}
Reason for revert:
The try server has been reconfigured to not use remote_run for the webrtc/ios recipe now, and builds are passing.
Original issue's description:
> CQ: Temporarily disable iOS Simulator trybots
>
> BUG=637666
> TBR=ehmaldonado@webrtc.org
> NOTRY=True
>
> Committed: https://crrev.com/414eb181d26a794e17f8e0206fa4a7efc116f75a
> Cr-Commit-Position: refs/heads/master@{#13738}
TBR=ehmaldonado@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=637666
Review-Url: https://codereview.webrtc.org/2242173002
Cr-Commit-Position: refs/heads/master@{#13755}
Also fixed one small chromium-style error in the new mixer.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2234293002
Cr-Commit-Position: refs/heads/master@{#13752}
The last in-tree call site recently disappeared, so they were unused.
BUG=webrtc:5922
Review-Url: https://codereview.webrtc.org/2066473002
Cr-Commit-Position: refs/heads/master@{#13751}
tests.
Note: The webrtc/base/test/ folder is new.
Currently not used, I intend to use this in another CL.
BUG=chromium:627816
NOPRESUBMIT=TRUE
NOTRY=TRUE
Review-Url: https://codereview.webrtc.org/2238073003
Cr-Commit-Position: refs/heads/master@{#13750}
They always fail, because RED isn't supported.
BUG=webrtc:5922
Review-Url: https://codereview.webrtc.org/2055753002
Cr-Commit-Position: refs/heads/master@{#13743}
The folder structure is now as was agreed on in the 'Slim and Modular
WebRTC' effort. Also added some dependencies that were previously in
another part of the tree.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2238803002
Cr-Commit-Position: refs/heads/master@{#13742}
If the data transport is destroyed while data is buffered (due to
the PC being closed, or a description set with data rejected), the
data channel was getting stuck in a "closing" state, waiting to
finish sending its buffered data. But since there's no more transport,
it will never get another chance to send buffered data.
It just needs to terminate non-gracefully and discard the buffered data
in this situation.
R=skvlad@webrtc.org, zhihuang@webrtc.org
Review URL: https://codereview.webrtc.org/2235843003 .
Cr-Commit-Position: refs/heads/master@{#13737}
The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.
The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.
After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.
BUG=webrtc:1953,webrtc:2383
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2125823004 .
Cr-Commit-Position: refs/heads/master@{#13734}
The test worked by sleeping a certain time, then checking that the
difference between recv timestamps before and after the sleep was
within some margin of the requested sleep time.
However, this means that imprecision of SleepMs makes the test flaky.
This source of flakiness can be removed by comparing to the actual
time slept instead of the requested time.
Also making the margin larger, to further reduce the likelihood of
flakiness.
R=pthatcher@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2111043004 .
Cr-Commit-Position: refs/heads/master@{#13733}
RTCPeerConnectionFactory.createPeerConnection did not check the return
value of the native createPeerConnection() - so when the native PC
fails to be created, it could end up attempting to use a null pointer.
The change makes it return nil when the creation fails. The application
can then detect and respond to the failure.
Review-Url: https://codereview.webrtc.org/2240633004
Cr-Commit-Position: refs/heads/master@{#13732}
