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:
Breaks downstream code, so revert again. Yay.
Original issue's description:
> Move FilePlayer and FileRecorder to Voice Engine
>
> Because Voice Engine was the only user.
>
> (This is a re-land of https://codereview.webrtc.org/2037623002, which
> had to be reverted.)
>
> NOPRESUBMIT=True
>
> Committed: https://crrev.com/dc65ea29b3270ad418050658ad962ddd33ee70c1
> Cr-Commit-Position: refs/heads/master@{#13757}
TBR=perkj@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2245153002
Cr-Commit-Position: refs/heads/master@{#13758}
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}
Also update existing perf tests to use send side bwe.
BUG=webrtc:4604, chromium:522001
Review-Url: https://codereview.webrtc.org/2227733004
Cr-Commit-Position: refs/heads/master@{#13726}
Since all FrameObjects have a reference to its PacketBuffer and since
the PacketBuffer can be thrown away at any moment the PacketBuffer
has to be ref counted in order to avoid FrameObjects dereferencing a potentially
destroyed object.
BUG=webrtc:5514
R=danilchap@webrtc.org, mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2199133004 .
Cr-Commit-Position: refs/heads/master@{#13725}
