Replaces cricket::VideoFrame::SetToBlack and
cricket::WebRtcVideoFrame::InitToBlack, which are deleted.
Refactors the black frame logic in VideoBroadcaster, and a few of the
tests.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2029273004
Cr-Commit-Position: refs/heads/master@{#13063}
BUG=webrtc:5949
TESTED=Built and ran the tests on Mac.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2040073002
Cr-Commit-Position: refs/heads/master@{#13061}
In https://codereview.webrtc.org/2034923003 it was discovered
that a test binary rtc_sdk_peerconnection_objc_tests was
a dependency to rtc_unittests. Unfortunately gtest doesn't
include dependent executables into the same test executable;
only libraries (so theses tests weren't run).
This CL incorporates those tests into rtc_unittests and
does the same changes to the GN build.
BUG=webrtc:5949
TESTED=Built and ran rtc_unittests locally on Mac.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2041743003
Cr-Commit-Position: refs/heads/master@{#13060}
This CL adds support for an extension on RTP frames to allow the sender
to specify the minimum and maximum playout delay limits.
The receiver makes a best-effort attempt to keep the capture-to-render delay
within this range. This allows different types of application to specify
different end-to-end delay goals. For example gaming can support rendering
of frames as soon as received on receiver to minimize delay. A movie playback
application can specify a minimum playout delay to allow fixed buffering
in presence of network jitter.
There are no tests at this time and most of testing is done with chromium
webrtc prototype.
On chromoting performance tests, this extension helps bring down end-to-end
delay by about 150 ms on small frames.
BUG=webrtc:5895
Review-Url: https://codereview.webrtc.org/2007743003
Cr-Commit-Position: refs/heads/master@{#13059}
Previously raw pointers were used for owned DesktopFrame instances.
Updated all screen and window capturer implementations to use
std::unique_ptr<>.
Also includes some other cleanups in the capturers:
- s/NULL/nullptr
- moved default initializers to class definition.
BUG=webrtc:5950
Review-Url: https://codereview.webrtc.org/1988783003
Cr-Commit-Position: refs/heads/master@{#13058}
This moves the implementation specific methods to separate classes
(RtpSenderInternal/RtpReceiverInternal) so that the interface classes
represent the interface that external applications can rely on.
The reason this wasn't done earlier was that PeerConnection needed
to store proxy pointers, but also needed to access implementation-
specific methods on the underlying objects. This is now possible
by using "RtpSenderProxyWithInternal<RtpSenderInternal>", which is a proxy
that implements RtpSenderInterface but also provides direct access
to an RtpSenderInternal.
Review-Url: https://codereview.webrtc.org/2023373002
Cr-Commit-Position: refs/heads/master@{#13056}
When the fake clock's time is advanced, it now ensures all pending
queued messages have been dispatched. This allows us to write a
"SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
until the target time.
Useful in this case, where we know the STUN timeout should take a total
of 9500ms, but it would be overly complex to write test code that waits
for each individual timeout, ensures a STUN packet has been
retransmited, etc.
(The test described above *should* be written, but it belongs in
p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
Review-Url: https://codereview.webrtc.org/2024813004
Cr-Commit-Position: refs/heads/master@{#13052}
The STUN fuzzer is split into two parts: validation and parsing. The
latter should be able to handle invalid packets instead of assuming
the validation deals with them, since an adversary could set a valid
HMAC on an invalid packet.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2044523002
Cr-Commit-Position: refs/heads/master@{#13050}
The iOS GN bots are the only ones using MB, which seems to enable
Goma by default. Since Goma has started supporting autostart, disable
it for now until a goma start step is added to the bots.
BUG=chromium:617541
TBR=phoglund@webrtc.org
Review URL: https://codereview.webrtc.org/2045583002 .
Cr-Commit-Position: refs/heads/master@{#13049}
Reason for revert:
There seems to be a TSan warning that wasn't caught by the trybot: https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/6732/steps/peerconnection_unittests/logs/stdio
Apparently a thread is still alive even after destroying WebRTCSession. Need to think of a way to fix this, without adding a critical section around g_clock (since that would hurt performance).
Original issue's description:
> Improving the fake clock and using it to fix a flaky STUN timeout test.
>
> When the fake clock's time is advanced, it now ensures all pending
> queued messages have been dispatched. This allows us to write a
> "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
> until the target time.
>
> Useful in this case, where we know the STUN timeout should take a total
> of 9500ms, but it would be overly complex to write test code that waits
> for each individual timeout, ensures a STUN packet has been
> retransmited, etc.
>
> (The test described above *should* be written, but it belongs in
> p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
>
> Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a
> Cr-Commit-Position: refs/heads/master@{#13043}
TBR=pthatcher@webrtc.org,tommi@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/2038213002
Cr-Commit-Position: refs/heads/master@{#13045}
When the fake clock's time is advanced, it now ensures all pending
queued messages have been dispatched. This allows us to write a
"SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
until the target time.
Useful in this case, where we know the STUN timeout should take a total
of 9500ms, but it would be overly complex to write test code that waits
for each individual timeout, ensures a STUN packet has been
retransmited, etc.
(The test described above *should* be written, but it belongs in
p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
Review-Url: https://codereview.webrtc.org/2024813004
Cr-Commit-Position: refs/heads/master@{#13043}
Using an "EXPECT_WAIT" pattern with a long timeout rather than calling
"SleepMs" with a margin of 250ms.
BUG=webrtc:5953
Review-Url: https://codereview.webrtc.org/2029853002
Cr-Commit-Position: refs/heads/master@{#13040}
Everything except the dependency on
sdk/sdk_tests.gyp:rtc_sdk_peerconnection_objc_tests is included.
That one actually doesn't make those tests run as part of rtc_unittests
(by design). Fixing that + add them will done in aseparate CL.
BUG=webrtc:5949
TESTED=Built and ran rtc_unittests on Mac.
Verified the number of tests matched a run on the bot (1213 tests executed).
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/2034923003 .
Cr-Commit-Position: refs/heads/master@{#13036}
Reason for revert:
Broke chromium builder
Original issue's description:
> Use std::unique_ptr<> to pass frame ownership in DesktopCapturer impls.
>
> Previously raw pointers were used for owned DesktopFrame instances.
> Updated all screen and window capturer implementations to use
> std::unique_ptr<>.
>
> Also includes some other cleanups in the capturers:
> - s/NULL/nullptr
> - moved default initializers to class definition.
>
> BUG=webrtc:5950
>
> Committed: https://crrev.com/4a627a8c13554d12412cabb8f751caee6e61ee32
> Cr-Commit-Position: refs/heads/master@{#13032}
TBR=wez@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5950
Review-Url: https://codereview.webrtc.org/2030333003
Cr-Commit-Position: refs/heads/master@{#13033}
Previously raw pointers were used for owned DesktopFrame instances.
Updated all screen and window capturer implementations to use
std::unique_ptr<>.
Also includes some other cleanups in the capturers:
- s/NULL/nullptr
- moved default initializers to class definition.
BUG=webrtc:5950
Review-Url: https://codereview.webrtc.org/1988783003
Cr-Commit-Position: refs/heads/master@{#13032}
With the current order of stop capture processing on Android,
OnMemoryBufferFrame and OnTextureFrame may be called halfway through
Stop(). They must therefore check for the case of a null capturer_.
There used to be such checks, but they were accidantally removed in
commit #12895, cl https://codereview.webrtc.org/1973873003.
BUG=webrtc:5966
R=perkj@webrtc.org, sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2033943004 .
Cr-Commit-Position: refs/heads/master@{#13031}
The only thing that differs from the previous attempt in
https://codereview.webrtc.org/1979933002/ is that none of
the new targets are not hooked up to the webrtc target in
webrtc/BUILD.gn, which should make it not break the
chromium.webrtc.fyi bots.
Add BUILD.gn files for webrtc/{api,media,libjingle,p2p,pc} in
preparation for removing src/third_party/libjingle in Chromium.
Changes between previous attempt and the one before that
(https://codereview.webrtc.org/1973313002) are:
* Added libstunprober target
* Adjusted warnings for Chromium's clang plugins
* webrtc/pc/externalhmac.{h,cc} added for Chromium builds.
BUG=webrtc:4256
NOTRY=True
NOPRESUBMIT=True
TBR=perkj@webrtc.org, tommi@webrtc.org
Review-Url: https://codereview.webrtc.org/2037983002
Cr-Commit-Position: refs/heads/master@{#13030}
This shouldn't be needed, but because the receiver assumes RTX packets
contain RED if configured to receive them (due to an incompatibility
issue), we also have to make sure we send them for now.
BUG=webrtc:5675
Review-Url: https://codereview.webrtc.org/2033763002
Cr-Commit-Position: refs/heads/master@{#13024}
This means there's only one thread hop to the worker thread.
At the video engine level, SetOptions and SetSource
are combined into one method (all within the same critical section)
which ensures that no frame will be encoded while SetVideoSend
is only partially finished.
BUG=webrtc:5691
Review-Url: https://codereview.webrtc.org/1838413002
Cr-Commit-Position: refs/heads/master@{#13022}
This cl split the class MediaOptimization into two parts. One that deals with frame dropping and stats and one new class called ProtectionBitrateCalculator that deals with calculating the needed FEC parameters and how much of the estimated network bitrate that can be used by an encoder
Note that the logic of how FEC and the needed bitrates is not changed.
BUG=webrtc:5687
R=asapersson@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1972083002 .
Cr-Commit-Position: refs/heads/master@{#13018}
